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Preface  Volume  10 

Andrew  Gordon,  Andrew  Pitts  and  Carolyn  Talcott 

Abstract 

This  issue  of  ENTCS  is  an  unrefereed  conference  record  of  talks  presented  at  the  Second 
Workshop  on  Higher  Order  Operational  Techniques  in  Semantics  (HOOTS  H)  held  at  Stanford 
University,  December  8-11, 1997.  The  meeting  was  organised  by  A.  Gordon,  A.  Pitts  and  C. 
Talcott  with  generous  sponsorship  from  Harlequin  Ltd,  NSF  and  ONR.  The  first  HOOTS 
workshop  was  held  October  28-30, 1995  as  part  of  the  University  of  Cambridge  Isaac  Newton 
Institute  research  programme  on  Semantics  of  Computation  (July-Dee  1995). 

The  study  of  operational  techniques  for  higher-order  languages  is  now  a  thriving  area,  with  much 
research  activity  going  on  world-wide.  An  important  open  problem  is  a  theory  of  program 
equivalence  for  languages  with  higher-order  features,  including  functions  and  objects.  Techniques 
for  defining  and  reasoning  about  equivalence  and  other  properties  of  higher-order  programs  have 
emerged  in  distinct  communities,  including  the  concurrency,  functional  programming  and  type 
theory  communities.  The  purpose  of  the  HOOTS  workshops  was  to  bring  researchers  from  these 
communities  together  to  discuss  current  trends  in  the  theory  of  operational  semantics,  its 
application  to  higher-order  languages  and  its  connection  with  more  established  semantic 
techniques. 

Papers  presented  at  HOOTS  n  covered  a  broad  range  of  topics: 

O  techniques  such  as  bisimulation  and  logical  relations  for  reasoning  about  contextual 
equivalence 

O  alternative  program  relations  such  as  operational  subsumption,  and  evaluation  rules  for 
program  contexts 

O  operational  models  including  adaptation  of  big-step  evaluation  semantics  to  provide 
capabilities  of  small-step  and  denotational  semantics  forms,  flow  graphs,  and  history 
dependent  automata 

O  higher-order  programming  calculi  including:  imperative  call-by-need  lambda  calculus, 
action  calculi,  process  calculi  for  reasoning  about  mobility  and  security,  interaction  of  actors 


and  pi  calculus  agents 

O  approaches  to  program  analysis  and  verification,  including:  logics  for  control  flow  analysis, 
monadic  type  systems,  and  diagramatic  specification  notation  for  actor  systems; 

O  programming  environment  tools  such  a  type  systems  for  Java  byte-code,  and  higher-order 
program  units  for  modularity. 

Programs  and  participants  lists  for  HOOTS  I  and  II  and  other  information  about  HOOTS,  past  and 
future  can  be  found  here 

[back  to  table  of  contents] 

Similarity  and  Bisimilarity  for  Countable  Non-Determinism  and 
Higher-Order  Functions 

(Extended  Abstract) 

Soren  Lassen  and  Corin  Pitcher 

Abstract 

This  paper  investigates  operationally-based  theories  of  a  simply-typed  functional  programming 
language  with  countable  non-determinism.  The  theories  are  based  upon  lower,  upper,  and  convex 
variants  of  applicative  similarity  and  bisimilarity,  and  the  main  result  presented  here  is  that  these 
relations  are  compatible.  The  differences  between  the  relations  are  illustrated  by  simple  examples, 
and  their  continuity  properties  are  discussed.  It  is  also  shown  that,  in  some  cases,  the  addition  of 
countable  non-determinism  to  a  programming  language  with  finite  non-determinism  alters  the 
theory  of  the  language. 

[Full  text]  (PostScript  631.2  Kb) 
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Parametric  Polymorphism  and  Operational  Equivalence 

(Preliminary  Version) 

Andy  Pitts 
Abstract 

Studies  of  the  mathematical  properties  of  impredicatively  polymorphic  types  have  for  the  most 
part  focused  on  the  polymorphic  lambda  calculus  of  Girard-Reynolds,  which  is  a  calculus  of  total 
polymorphic  functions.  This  paper  considers  polymorphic  types  from  a  functional  programming 
perspective,  where  the  partialness  arising  from  the  presence  of  fixpoint  recursion  complicates  the 
nature  of  potentially  infinite  (‘lazy’)  datatypes.  An  operationally-based  approach  to  Reynolds’ 


notion  of  relational  parametricity  is  developed  for  an  extension  of  Plotkin’s  PCF  with  forall-types 
and  lazy  lists.  The  resulting  logical  relation  is  shown  to  be  a  useful  tool  for  proving  properties  of 
polymorphic  types  up  to  a  notion  of  operational  equivalence  based  on  Morris-style  contextual 
equivalence. 

[Full  text]  (PostScript  756.3  Kb) 
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Operational  Subsumption,  an  Ideal  Model  of  Subtyping 

Laurent  Dami 

Abstract 

In  a  previous  paper  we  have  defined  a  semantic  preorder  called  operational  subsumption,  which 
compares  terms  according  to  their  error  generation  behaviour.  Here  we  apply  this  abstract 
framework  to  a  concrete  language,  namely  the  Abadi-Cardelli  object  calculus.  Unlike  most 
semantic  studies  of  objects,  which  deal  with  typed  equalities  and  therefore  require  explicitly  typed 
languages,  we  start  here  from  a  untyped  world.  Type  inference  is  introduced  in  a  second  step, 
together  with  an  ideal  model  of  types  and  subtyping.  We  show  how  this  approach  flexibly 
accommodates  for  several  variants,  and  finally  propose  a  novel  semantic  interpretation  of 
structural  subtyping  as  embedding-projection  pairs. 

[Full  text]  (PostScript  673.1  Kb) 
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An  Operational  Understanding  of  Bisimulation  from  Open  Maps 

Glynn  Winskel 

Abstract 

Models  can  be  given  to  a  range  of  progranuning  languages  combining  concurrent  and  functional 
features  in  which  presheaf  categories  are  used  as  the  semantic  domains  (instead  of  the  more  usual 
complete  partial  orders).  Once  this  is  done  the  languages  inherit  a  notion  of  bisimulation  from  the 
“open”  maps  associated  with  the  presheaf  categories.  However,  although  there  are 
methodological  and  mathematical  arguments  for  favouring  semantics  using  presheaf 
categories — in  particular,  there  is  a  "domain  theory"  based  on  presheaf  categories  which 
systematises  bisimulation  at  higher-order— it  is  as  yet  far  from  a  routine  matter  to  read  off  an 
"operational  characterisation";  by  this  I  mean  an  equivalent  coinductive  definition  of  bisimulation 
between  terms  based  on  the  operational  semantics.  I  hope  to  illustrate  the  issues  on  a  little 
process-passing  language.  This  is  joint  work  with  Gian  Luca  Cattani. 


[back  to  table  of  contents] 


Premonoidal  categories  and  flow  graphs 

Alan  Jeffrey 

Abstract 

We  give  two  presentations  of  the  semantics  of  programs:  a  categorical  semantics  based  on  Power 
and  Robinson’s  symmetric  premonoidal  categories  and  Joyal,  Street  and  Verity’s  traced  monoidal 
categories,  and  a  graphical  semantics  based  on  mixed  control  flow  and  data  flow  graphs.  We  show 
how  these  semantics  are  related,  and  sketch  how  the  2-categorical  versions  could  be  used  to  give 
an  operational  semantics  for  programs.  The  semantics  is  similar  to  Hasegawa’s  presentation  of 
Milner  and  Gardner’s  name-free  action  calculi. 

[back  to  table  of  contents] 

A  Type-theoretic  Description  of  Action  Calculi 

Philippa  Gardner 

Abstract 

Action  calculi,  introduced  by  Milner,  provide  a  framework  for  investigating  models  of  interaction. 
This  talk  will  focus  on  the  connection  between  action  calculi  and  known  concepts  arising  from 
type  theory.  The  aim  of  this  work  is  to  isolate  what  is  distinctive  about  action  calculi,  and  to 
investigate  the  potential  of  action  calculi  as  an  underlying  framework  for  many  kinds  of 
computational  behaviour. 

The  first  part  of  the  talk  will  introduce  action  calculi.  In  the  second  part.  I’ll  give  a  type-theoretic 
account  of  action  calculi,  using  the  general  binding  operators  of  Aczel.  I  will  discuss  two 
extensions:  higher-order  action  calculi  which  correspond  to  Moggi’s  commutative  computational 
lambda-calculus,  and  linear  action  calculi  which  correspond  to  the  linear  type  theories  of  Barber 
and  Benton. 

This  talk  is  based  on  joint  work  with  Andrew  Barber,  Masahito  Hasegawa  and  Gordon  Plotkin.  If 
time,  I  will  also  describe  current  work  arising  from  the  connections  described  above. 

[back  to  table  of  contents] 

Correctness  of  Monadic  State:  An  Imperative  Call-by-Need 
Calculus 

Zena  Ariola  and  Amr  Sabry 


Abstract 


The  extension  of  Haskell  with  a  built-in  state  monad  combines  mathematical  elegance  with 
operational  efficiency: 

O  Semantically,  at  the  source  language  level,  constructs  that  act  on  the  state  are  viewed  as 
functions  that  pass  an  explicit  store  data  structure  around. 

O  Operationally,  at  the  implementation  level,  constructs  that  act  on  the  state  are  viewed  as 
statements  whose  evaluation  has  the  side-effect  of  updating  the  implicit  global  store  in  place. 

There  are  several  unproven  conjectures  that  the  two  views  are  consistent.  Recently,  we  have  noted 
that  the  consistency  of  the  two  views  is  far  from  obvious:  all  it  takes  for  the  implementation  to 
become  unsound  is  one  judiciously-placed  beta-step  in  the  optimization  phase  of  the  compiler. 
This  discovery  motivates  the  current  paper  in  which  we  formalize  and  show  the  correctness  of  the 
implementation  of  monadic  state.  For  the  proof,  we  first  design  a  typed  call-by-need  language  that 
models  the  intermediate  language  of  the  compiler,  together  with  a  type-preserving  compilation 
map.  Second,  we  show  that  the  compilation  is  semantics-preserving  by  proving  that  the 
compilation  of  every  source  axiom  yields  an  observational  equivalence  of  the  target  language. 
Because  of  the  wide  semantic  gap  between  the  source  and  target  languages,  we  perform  this  last 
step  using  a  number  of  intermediate  languages.  The  imperative  call-by-need  lambda-calculus  is  of 
independent  interest  for  reasoning  about  system-level  Haskell  code  providing  services  such  as 
memo-functions,  generation  of  new  names,  etc,  and  is  the  starting  point  for  reasoning  about  the 
space  usage  of  Haskell  programs. 

[back  to  table  of  contents] 

Monadic  Type  Systems:  Pure  Type  Systems  for  Impure  Settings 

(Preliminary  Report) 

Gilles  Barthe ,  John  Hatclijfand  Peter  Thiemann 

Abstract 

Pure  type  systems  and  computational  monads  are  two  parameterized  frameworks  that  have  proved 
to  be  quite  useful  in  both  theoretical  and  practical  applications.  We  join  the  foundational  concepts 
of  both  of  these  to  obtain  monadic  type  systems.  Essentially,  monadic  type  systems  inherit  the 
parameterized  higher-order  type  stmcture  of  pure  type  systems  and  the  monadic  term  and  type 
stmcture  used  to  capture  computational  effects  in  the  theory  of  computational  monads.  We 
demonstrate  that  monadic  type  systems  nicely  characterize  previous  work  and  suggest  how  they 
can  support  several  new  theoretical  and  practical  applications. 

A  technical  foundation  for  monadic  type  systems  is  laid  by  recasting  and  scaling  up  the  main 
results  from  pure  type  systems  (confluence,  subject  reduction,  strong  normalisation  for  particular 
classes  of  systems,  etc.)  and  from  operational  presentations  of  computational  monads  (notions  of 
operational  equivalence  based  on  applicative  similarity,  co-induction  proof  techniques). 

We  demonstrate  the  use  of  monadic  type  systems  with  case  studies  of  several  call-by-value  and 
call-by-name  systems.  Our  framework  allows  to  capture  the  restriction  to  value  polymorphism  in 
the  type  structure  and  is  flexible  enough  to  accommodate  extensions  of  the  type  system,  e.g.,  with 


higher-order  polymorphism.  The  theoretical  foundations  make  monadic  type  systems  well-suited 
as  a  typed  intermediate  language  for  compilation  and  specialization  of  higher-order,  strict  and 
non-strict  functional  programs.  The  monadic  structure  guarantees  sound  compile-time 
optimizations  and  the  parameterized  type  structure  guarantees  sufficient  expressiveness. 

[Full  text]  (PostScript  1093.3  Kb) 
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Adapting  Big-Step  Semantics  to  Small-Step  Style:  Coinductive 
Interpretations  and  ‘‘Higher-Order”  Derivations 

Husain  Ibraheem  and  David  A.  Schmidt 

Abstract 

We  adapt  Kahn-style  (“big-step”)  natural  semantics  to  take  on  desirable  aspects  of  small-step  and 
denotational  semantics  forms,  more  precisely:  (i)  the  ability  to  express  divergent  computations;  (ii) 
the  ability  to  reason  about  the  (length  of  a)  computation  of  a  derivation;  and  (iii)  the  ability  to 
compute  upon  and  reason  about  higher-order  values.  To  accomplish  these  results,  we  extend  the 
classical,  inductive  interpretation  of  natural  semantics  with  coinduction  mechanisms  and  use 
“negative”  rules  to  express  divergence.  A  simple  reformatting  of  the  syntax  of  derivations  allows 
a  simple  description  of  the  “length”  of  a  derivation.  Finally,  the  recoding  of  closure  values  into 
denotational-semantics-like  functions  lets  one  embed  derivations  within  closures  that  embed 
within  derivations;  in  this  sense,  the  semantics  becomes  “higher  order.”  Examples  are  given  to 
support  the  definitional  developments. 

[Full  text]  (PostScript  564.9  Kb) 
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An  Operational  Semantics  Framework  Supporting  the 
Incremental  Construction  of  Derivation  Trees 

Allen  Stoughton 

Abstract 

We  describe  the  current  state  of  the  design  and  implementation  of  Dops,  a  framework  for 
Deterministic  Operational  Semantics  that  will  support  the  incremental  construction  of  derivation 
trees,  starting  from  term/input  pairs.  This  process  of  derivation  tree  expansion  may  terminate  with 
either  a  complete  derivation  tree,  explaining  why  a  term/input  pair  evaluates  to  a  particular  output, 
or  with  a  blocked  incomplete  derivation  tree,  explaining  why  a  term/input  pair  fails  to  evaluate  to 
an  output;  or  the  process  may  go  on  forever,  yielding,  in  the  limit,  an  infinite  incomplete 
derivation  tree,  explaining  why  a  term/input  pair  fails  to  evaluate  to  an  output. 


The  Dops  metalanguage  is  a  typed  lambda  calculus  in  which  all  expressions  converge.  Semantic 
rules  are  specified  by  lambda  terms  involving  resumptions,  which  are  used  by  a  rule  to  consume 
the  outputs  of  sub-evaluations  and  then  resume  the  rule’s  work.  A  rule’s  type  describes  the  number 
and  kinds  of  sub-evaluations  that  the  rule  can  initiate,  and  indicates  whether  the  rule  can  block. 

The  semantics  of  Dops  is  defined  in  an  object  language-independent  manner  as  a  small-step 
semantics  on  concrete  derivation  trees:  trees  involving  resumptions.  These  concrete  derivation 
trees  can  then  be  abstracted  into  ordinary  derivation  trees  by  forgetting  the  resumptions. 
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Computing  with  Contexts:  A  simple  approach 

Dave  Sands 

Abstract 

This  article  describes  how  the  use  of  a  higher-order  syntax  representation  of  contexts  [due  to  A. 
Pitts]  combines  smoothly  with  higher-order  syntax  for  evaluation  rules,  so  that  definitions  can  be 
extended  to  work  over  contexts.  This  provides  "for  free"  --  without  the  development  of  any  new 
language-specific  context  calculi  -  evaluation  rules  for  contexts  which  commute  with  hole-filling. 
We  have  found  this  to  be  a  useful  technique  for  directly  reasoning  about  operational  equivalence. 

A  small  illustration  is  given  based  on  a  unique  fixed-point  induction  principle  for  a  notion  of 
guarded  context  in  a  functional  language. 
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Flow  Logic  and  Operational  Semantics 

Flemming  Nielson  and  Hanne  Riis  Nielson 

Abstract 

Flow  logic  is  a  “fast  prototyping’’  approach  to  program  analysis  that  shows  great  promise  of 
being  able  to  deal  with  a  wide  variety  of  languages  and  caleuli  for  computation.  However, 
seemingly  innocent  choices  in  the  flow  logic  as  well  as  in  the  operational  semantics  may  inhibit 
proving  the  analysis  correct.  Our  main  conclusion  is  that  environment  based  semantics  is  more 
flexible  than  either  substitution  based  semantics  or  semantics  making  use  of  structural  congruences 
(like  alpha-renaming). 

[Full  text]  (PostScript  562.5  Kb) 
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An  Introduction  to  History  Dependent  Automata 

Ugo  Montanari  and  Marco  Pistore 

Abstract 

Automata  (or  labeled  transition  systems)  are  widely  used  as  operational  models  in  the  field  of 
process  description  languages  like  CCS.  There  are  however  classes  of  formalisms  that  are  not 
modelled  adequately  by  the  automata.  This  is  the  case,  for  instance,  of  the  pi-calculus,  an 
extension  of  CCS  where  channels  can  be  used  as  values  in  the  communications  and  new  channels 
can  be  created  dynamically.  Due  to  the  necessity  to  represent  the  creation  of  new  channels,  infinite 
automata  are  obtained  in  this  case  also  for  very  simple  agents  and  a  non-standard  definition  of 
bisimulation  is  required. 

In  this  paper  we  present  an  enhanced  version  of  automata,  called  history  dependent  automata,  that 
are  adequate  to  represent  the  operational  semantics  of  pi-calculus  and  of  other  history  dependent 
formalisms.  We  also  define  a  bisimulation  equivalence  on  history  dependent  automata,  that 
captures  pi-calculus  bisimulation. 

[Full  text]  (PostScript  778.1  Kb) 
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Can  Actors  and  pi- Agents  Live  Together? 

Ugo  Montanari  and  Carolyn  Talcott 

Abstract 

The  syntax  and  semantics  of  actors  and  pi-agents  is  first  defined  separately,  using  a  uniform, 

‘  ‘unbiased’  ’  approach.  New  coordination  primitives  are  then  added  to  the  union  of  the  two  calculi 
which  allow  actors  and  pi-agents  to  cooperate. 
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Specification  Diagrams  for  Actor  Systems 

Scott  Smith 

Abstract 

Traditional  approaches  to  specifying  distributed  systems  include  temporal  logic  specification  (e.g. 
TLA),  and  process  algebra  specification  (e.g.  LOTOS).  We  propose  here  a  new  form  of  graphical 


notation  for  specifying  open  distributed  object  systems.  The  primary  design  goal  is  to  make  a  form 
of  notation  for  defining  message-passing  behavior  that  is  expressive,  intuitively  understandable, 
and  that  has  a  formal  underlying  semantics.  We  describe  the  language  and  its  use  through 
presentation  of  a  series  of  example  specifications.  We  also  give  an  operationally-based  interaction 
path  semantics  for  specification  diagrams. 

[Full  text]  (PostScript  724.2  Kb) 
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Mobile  Ambients 

(Extended  Abstract) 

Luca  Cardelli  and  Andrew  D.  Gordon 

Abstract 

There  are  two  distinct  areas  of  work  in  mobility:  "mobile  computing",  concerning  computation 
that  is  carried  out  in  mobile  devices,  and  "mobile  computation",  concerning  mobile  code  that 
moves  between  devices.  These  distinctions  are  destined  to  vanish.  We  aim  to  describe  all  aspects 
of  mobility  within  a  single  framework  that  encompasses  mobile  agents,  the  ambients  where  agents 
interact  and  the  mobility  of  the  ambients  themselves. 

The  main  difficulty  with  mobile  computation  is  not  in  mobility  per  se,  but  in  the  crossing  of 
administrative  domains.  Mobile  programs  must  be  equipped  to  navigate  a  hierarchy  of  domains,  at 
every  step  obtaining  authorization  to  move  further.  Therefore,  at  the  most  fundamental  level  we 
need  to  capture  notions  of  locations,  of  mobility  and  of  authorization  to  move. 

We  identify  "mobile  ambients"  as  a  fundamental  abstraction  that  generalizes  both  dynamic  agents 
and  the  static  domains  they  must  cross.  From  a  formal  point  of  view  we  develop  a  simple  but 
computationally  powerful  calculus  that  directly  embodies  domains  and  mobility  (and  little  else). 
The  calculus  forms  the  basis  of  a  small-language/Java-library.  We  demonstrate  the  expressiveness 
of  the  approach  by  a  series  of  examples,  including  showing  how  a  notion  such  as  "crossing  a 
firewall"  has  a  direct  and  analyzable  interpretation. 
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Secure  Implementation  of  Channel  Abstractions 

Martin  Abadi,  Cedric  Foumet  and  Georges  Gonthier 


Abstract 


While  cryptography  is  useful  for  distributed  applications  and  fun  even  for  application 
progranuners,  cryptographic  manipulations  by  and  large  do  not  belong  in  application  code.  Ideally, 
application  code  should  not  be  concerned  with  the  details  of  key  management,  but  should  instead 
rely  on  abstractions  and  services  that  encapsulate  cryptographic  protocols.  In  recent  years,  several 
APIs  (application  program  interfaces)  for  security  have  appeared,  providing  such  abstractions  and 
services.  Although  there  are  substantial  differences  among  these  APIs,  they  generally  offer  the 
promise  of  making  application  code  more  modular,  simpler,  and  ultimately  more  robust. 

In  this  talk  we  consider  high-level  abstractions  that  largely  hide  the  difficulties  of  network  security 
from  applications.  These  high-level  abstractions  support  the  pleasing  illusion  that  all  application 
address  spaces  are  on  the  same  machine,  and  that  a  centralized  operating  system  provides  security 
for  them.  In  reality,  these  address  spaces  could  be  spread  across  a  network,  and  security  could 
depend  on  several  local  operating  systems  and  on  cr5^tographic  protocols  across  machines.  Thus, 
the  application  code  need  not  be  concerned  with  the  security  implications  of  distribution. 
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Program  Units  as  Higher-Order  Modules 

Matthew  Flatt  and  Matthias  Felleisen 

Abstract 

We  have  designed  a  new  module  language  called  “program  units”.  Units  support  separate 
compilation,  independent  module  reuse,  cyclic  dependencies,  hierarchical  structuring,  and 
dynamic  linking.  In  this  paper,  we  present  untyped  and  typed  models  of  units. 
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Typed  Closure  Conversion  for  Recursively-Defined  Functions 

(Extended  Abstract) 

Greg  Morrisett  and  Robert  Harper 
Abstract 

Much  recent  work  on  the  compilation  of  statically  typed  languages  such  as  ML  relies  on  the 
propagation  of  type  information  from  source  to  object  code  in  order  to  increase  the  reliability  and 
maintainabilty  of  the  compiler  itself  and  to  improve  the  efficiency  and  verifiability  of  generated 
code.  To  achieve  this  the  program  transformations  performed  by  a  compiler  must  be  cast  as 
type-preserving  translations  between  typed  intermediate  languages.  In  earlier  work  with  Minamide 


we  studied  one  important  compiler  transformation,  closure  conversion,  for  the  case  of  pure 
simply-typed  and  polymorphic  lambda-calculus.  Here  we  extend  the  treatment  of  simply-typed 
closure  conversion  to  account  for  recursively-defined  functions  such  as  are  found  in  ML.  We 
consider  three  main  approaches,  one  based  on  a  recursive  code  construct,  one  based  on  a 
self-referential  data  structure,  and  one  based  on  recursive  types.  We  discuss  their  relative 
advantages  and  disadvantages,  and  sketch  correctness  proofs  for  these  transformations  based  on 
the  method  of  logical  relations. 
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A  Type  System  For  Object  Initialization  In  the  Java  Bytecode 
Language 

Steve  Freund  and  John  Mitchell 

Abstract 

In  the  standard  Java  implementation,  a  Java  language  program  is  compiled  to  Java  bytecode  and 
this  bytecode  is  then  interpreted  by  the  Java  Virtual  Machine.  Since  bytecode  may  be  written  by 
hand,  or  corrupted  during  network  transmission,  the  Java  Virtual  Machine  contains  a  bytecode 
verifier  that  performs  a  number  of  consistency  checks  before  code  is  interpreted.  As  one-step 
towards  a  formal  specification  of  the  verifier,  we  describe  a  precise  specification  of  a  subset  of  the 
bytecode  language  dealing  with  object  creation  and  initialization. 
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Abstract 

This  paper  investigates  operationally-based  theories  of  a  simply-typed  functional 
programming  language  with  countable  non-determinism.  The  theories  are  based 
upon  lower,  upper,  and  convex  variants  of  applicative  similarity  and  bisimilarity, 
and  the  main  result  presented  here  is  that  these  relations  are  compatible.  The 
differences  between  the  relations  are  illustrated  by  simple  examples,  and  their  con¬ 
tinuity  properties  are  discussed.  It  is  also  shown  that,  in  some  cases,  the  addition  of 
countable  non-determinism  to  a  programming  language  with  finite  non-determinism 
alters  the  theory  of  the  language. 

Key  words:  lambda-calculus,  applicative  bisimilarity,  countable 

non-determinism. 


1  Introduction 

Non-deterministic  programs  are  used  in  the  study  of  concurrent  systems,  to 
abstract  from  scheduling  details,  and  in  methodologies  for  program  construc¬ 
tion,  where  specifications  are  regarded  as  non-deterministic  programs.  In  re¬ 
cent  years,  several  non-deterministic  higher-order  languages  have  been  pro¬ 
posed  in  the  literature  in  these  areas  (see,  e.g.,  [28,4]).  Non-determinism  is 
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also  found  as  an  integrated  feature  of  the  higher-order,  operationally-based 
semantic  meta-language  of  action  semantics  [19].  In  this  paper  we  use  op¬ 
erational  techniques  to  study  the  interaction  between  non-determinism  and 
higher-order  functions  in  an  idealised,  minimal  programming  language. 

We  investigate  three  variants,  lower,  upper,  and  convex,  of  applicative  sim¬ 
ilarity  and  bisimilarity  for  a  simply-typed  functional  programming  language 
with  countable  non-determinism.  This  builds  upon  work  by  Abramsky,  Howe, 
and  Ong  [1,11,12,21]  for  deterministic  and  finitely  non-deterministic  higher- 
order  calculi. 

The  variants  of  the  relations  correspond  to  the  different  constructions  on 
preorders  that  are  used  to  characterise  the  lower,  upper  and  convex  pow- 
erdomains.  Their  definitions  refer  to  an  inductively  defined  may  convergence 
relation  between  terms,  and  also  a  co-inductively  defined  may  divergence  pred¬ 
icate  on  terms,  for  the  upper  and  convex  variants.  For  each  variant  there  is 
an  applicative  similarity  preorder  and  an  applicative  bisimilarity  equivalence 
relation,  both  defined  by  co-induction.  In  addition,  the  applicative  similarity 
preorders  determine  mutual  applicative  similarity  equivalence  relations  that 
do  not  coincide  with  applicative  bisimilarity.  The  proliferation  of  preorders 
and  equivalences  reflects  the  conflicting  requirements  of  different  applications 
for  semantic  theories  of  non-determinism.  This  complexity  is  not  apparent 
in  the  absence  of  non-determinism,  because  the  nine  relations  defined  here 
collapse  to  just  two. 

It  is  of  fundamental  importance  to  know  whether  the  relations  are  com¬ 
patible,  i.e.,  are  they  preserved  by  the  constructors  of  the  language?  We 
prove  that  this  is  the  case  for  all  of  the  relations,  extending  methods  due  to 
Howe  and  Ong  that  were  previously  restricted  to  finitely  non-deterministic 
languages  for  the  upper  and  convex  variants.  By  the  use  of  induction  on  the 
derivation  of  a  must  convergence  judgement  (the  complement  of  the  may  di¬ 
vergence  predicate)  their  methods  are  extended  smoothly  to  a  language  with 
countable  non-determinism. 

Must  convergence  is  defined  inductively  via  a  finite  collection  of  infinitary 
rule  schema,  and  so  ordinal  heights  can  be  assigned  to  the  derivation  trees 
of  must  convergence  judgements  in  the  usual  way.  Such  trees  have  heights 
strictly  less  than  w  for  finite  non-determinism,  and  heights  strictly  less  than  the 
least  non-recursive  ordinal  for  countable  non-determinism.  This  allows 
us  to  prove  unwinding  theorems  for  fixed  points  terms  with  respect  to  must 
convergence:  a;-unwinding  in  the  case  of  finitely  non-deterministic  terms,  and 
a  more  unusual  a;f  ^-unwinding  for  countably  non-deterministic  terms. 

2  A  Functional  Language  with  Non-Determinism 

The  vehicle  for  the  examples  and  results  in  this  paper  is  a  variant  of  the  lan¬ 
guage  of  Moggi’s  computational  lambda-calculus  [17,7].  Within  the  computa¬ 
tional  lambda-calculus  there  is  a  distinction  between  values  and  computations 
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that  is  enforced  by  the  type  system  through  a  type-constructor  for  computa¬ 
tion  types.  There  are  mechanisms  for  creating  and  composing  the  programs 
of  computation  types. 

The  language  is  extended  with  an  operator  ?N  to  choose  any  natural  num¬ 
ber.  The  new  construct  is  the  sole  source  of  non-determinism  in  the  language, 
and,  because  it  is  assigned  an  appropriate  computation  type,  non-determinism 
is  restricted  to  the  computation  types.  This  restriction  is  convenient  because 
the  mechanism  for  composing  computations  can  be  used  to  control  when  non¬ 
determinism  is  resolved — an  alternative  is  to  incorporate  both  call-by-name 
and  call-by- value  abstractions  (see,  e.g.,  [22]).  In  addition,  although  the  ex¬ 
amples  presented  here  have  analogues  at  function  types,  they  are  simpler  at 
computation  types. 

The  types  of  the  language  are: 

a,  T  ::=  unit  |  nat  |  a  ->  r  |  P((7) 

The  computation  types  are  those  of  the  form  P(o'),  and  the  remaining  types 
are  called  deterministic  types. 

The  terms  of  the  language  are; 

L,M,N::=  a;  1  *  |  n  |  uop(M)  j  bop(M,N)  | 

if  L  then  M  else  N  \  Xx  :  a.  M  \  M  N  \ 

[M]  I  leta; :  (7  ^  MiniV  1  fixa: :  (7.  M  I  ?N 

where  x  ranges  over  a  countably  infinite  set  of  variables,  n  ranges  over  N,  and 
uop  and  bop  range  over  a  suitable  set  of  symbols  representing,  respectively, 
unary  and  binary  primitive  recursive  functions,  e.g.,  not,  plus,  leq.  For  the 
sake  of  economy,  booleans  are  represented  by  natural  numbers:  0  for  false, 
and  1  for  true.  The  primitive  recursive  functions  are  assumed  to  follow  this 
representation,  and  are  denoted,  e.g.,  (]not|)  :  N  — >  N,  dplusj),  (|leqD  :  — >  N. 
Variable  binding  terms  follow  the  usual  conventions  for  scope,  oi-conversion, 
and  type  annotations  to  ensure  uniqueness  of  typing.  The  notation  M[iV/x] 
denotes  the  capture-free  substitution  of  N  for  free  occurrences  of  x  in  M.  The 
canonical  terms  are: 

K  -k  \  n\  Xx  :  a.M  \  [M] 

The  type  assignment  rules  in  figure  1  are  based  on  those  of  the  compu¬ 
tational  lambda-calculus.  We  follow  the  convention  that  environments  are 
partial  functions,  and  that  F,  x  :  c  is  only  defined  when  x  is  not  in  the  domain 

of  r. 

The  sets  of  terms  and  canonical  terms  that  are  closed  and  well-typed  are 
Exp  and  Can  respectively.  A  term  that  is  closed  and  well-typed  is  called  a 
program.  The  set  of  programs  of  type  a  is  Exp„. 
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r  h  X  :  (T  (r(x)  =  (t)  r  h  a  :  unit  F  h  n  :  nat  (n  €  N 

r  h  M  :  nat  F  h  M  :  nat  F  h  iV  :  nat 

F  h  uop  (M)  :  nat  F  h  bop  (M,  N)  :  nat 

FhL:nat  FhMicr  FhiV:a 
F  f-  if  L  then  M  else  N  :  a 

r,x:a\-M:T  FI-M:<t->t  FhA^:<7 


T  ]-  Xx  :  a.  M  :  a  T  T  M  N  :  r 

T\-M:(t  T\-M:P{a)  F,  x  :  cr  h  AT :  P(r) 

FI-[M]:P(a)  F  h  letx  :  a  4=  Min  AT :  P(t) 

F,x  :  P((7)  h  M  :  P(a) 


F  h  fixx  :  P((t).  M  :  P(a) 


F  1-?N :  P(nat) 


Fig.  1.  Type  Assignment 


Many  of  the  examples  that  we  give  do  not  depend  on  the  existence  of 
distinct  canonical  programs  at  a  base  type,  and  in  such  cases  we  use  the  unit 
type  in  preference  to  nat. 

The  operational  semantics  is  presented  as  an  inductively  defined  evaluation 
relation  called  may  convergence,  between  programs  and  canonical  closed 
terms.  The  rules  are  shown  in  figure  2.  The  may  convergence  relation  is  not  a 
partial  function  because  of  the  rule  that  allows  ?N  to  converge  to  any  natural 
number. 

In  contrast  to  the  situation  for  deterministic  programs,  the  divergent  (non¬ 
terminating)  behaviour  of  a  non-deterministic  program  is  not  determined  by 
its  convergent  behaviour.  Following  [6,8,18]  we  define  a  may  divergence  predi¬ 
cate  on  programs  by  co-induction.  The  may  divergence  rules  are  given  in 
figure  3.  The  symbol  (— )  at  the  side  of  each  rule  is  used  to  indicate  that  the 
may  divergence  predicate  is  the  greatest  fixed  point  of  the  monotone  function 
determined  by  the  rules.  Note  that  there  is  some  redundancy  in  the  may  di¬ 
vergence  rules,  because  it  can  be  shown  that  programs  of  deterministic  types 
cannot  diverge. 

Examples  2.1  and  2.2  highlight  properties  of  the  programming  language 
that  are  relevant  in  the  sequel. 

Example  2.1  The  construct  for  sequencing  computations  in  the  computa¬ 
tional  lambda- calculus  provides  an  additional  degree  of  control  over  the  resolu¬ 
tion  of  non- determinism.  For  example,  a  call-by-value  abstraction  is  definable 
at  computation  types  (where  y  is  fresh  for  M): 

X'’x  :a.M^=  \y:  P(cr).  letx  :  cr  -4=  y  in  M 

The  call-by-value  abstraction  exhibits  (weak)  call-time  choice,  i.e.,  a  non- 
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K  K  {K  e  Can) 

M  n  M  ni  N  n2 

uop(M)  (|uop[)(n)  bop(M,  A^)  (|bopD(ni,n2) 

LiT'^yn  +  i  .  Lj|“^yo  n  iT^y  k 

if  L  then  M  else  N  K  ^  ^  if  L  then  M  else  N  K 

M  iT’^y  \x.  Ml  Ml  [N/x]  J^®^y  K 

Miv^®^y  K 

M  ^®^y  [Ml]  iV[Mi/a:]  J|®^y  K 
letar  ^M\nN  Jj.®^y  K 


M[Y\xx.  M/x]  ^®^y  K 
fixx.  M  ^®^y  K 


?N  V'’^y  [n]  (n  €  N) 


Fig.  2.  May  Convergence 


deterministic  program  of  type  P(<7)  is  resolved  to  program  of  type  a  at  the 
time  that  it  is  passed  as  an  argument. 

Example  2.2  Recursion  is  only  available  at  computation  types,  but  given  a 
term  T,  f  :  a  ^  P{t)  h  M  :  a  — >•  P(r)  the  following  acts  as  a  fixed  point 
(where  g  and  x  are  fresh  for  M ): 


r  h  Ax.  let  /  <=  fixp.  [Ax.  let  /  pinMx]  inMx  :  a  ->•  P(t) 


Non-determinism  is  often  introduced  via  a  binary  operator,  binary  erratic 
choice.  It  can  be  defined  in  the  programming  language  in  terms  of  ?N. 

Example  2.3  The  binary  erratic  choice  of  programs  M  and  N  of  the  same 
computation  type  is  defined  to  be  (where  y  is  fresh  for  M  and  N): 

(M  or  N)  let  y  <^=?N  in  if  y  then  M  else  N 

Non-determinism  is  informally  classified  by  the  cardinalities  of  the  sets  of 
convergent  behaviours  of  programs  that  cannot  diverge  (see  section  6  also). 
For  example,  the  binary  erratic  choice  of  deterministic  terms  is  said  to  be 
finitely  non-deterministic,  whereas  ?N  is  said  to  be  countably  non-deterministic. 
Konig’s  lemma  ensures  that  recursion  does  not  provide  a  route  from  finite  to 
countable  non-determinism. 

Example  2.4  The  program  below  can  converge  to  any  natural  number,  but 
may  also  diverge: 

h  fixx.  ([0]  or  let  y  ^  xin  [plus(y,  1)])  :  P(nat) 

It  cannot  be  distinguished  from  ?N  by  equivalences  that  ignore  divergent  be¬ 
haviour. 
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JV^may 


uop  (M)  fr'^^y 


bop  (M,  N) 

^^may 

if  L  then  M  else  N 
M 


bop  (M,  N) 


if  L  then  M  else  A?"  ■0'"'^^ 

^^may 


if  L  then  M  else  N 


{L  n  +  1  and  n  €  N) 


{L  iT^y  0) 


Mit^^y 

MiV^niay' 

M^”»ay 


Mi[N/x]t”'^y 

—  '■  - (M  .n.“^y  Xx.  Ml) 

MiV1f®ay  V 


N[Mi/x]  it^^y 


\etx  ^  M\nN  letx  4=  M  in  N  -ft-^ay 

AQixxJ4/x\j^_ 
f'lxx.M  'f|-'"ay 

Fig.  3.  May  Divergence 


(M  JJ.”ay  [Ml]) 


3  Similarity  and  Bisimilarity 

Abramsky  [1]  develops  a  notion  of  applicative  similarity  for  the  untyped  lazy 
lambda-calculus,  building  upon  earlier  work  of  Park  and  Milner  [16]  in  the 
context  of  process  calculi.  The  preorders  and  equivalences  described  in  this 
section  are  based  upon  Abramsky’s  work  and  subsequent  extensions  to  non- 
deterministic  functional  languages  by  Howe  and  Ong  [12,21]. 

There  are  two  fundamental  differences  between  the  deterministic  and  non- 
deterministic  settings:  applicative  bisimilarity  is  not  the  same  as  mutual  ap¬ 
plicative  similarity,  and  there  are  different  ways  of  ordering  non-deterministic 
programs  that  correspond  to  the  constructions  on  preorders  used  to  charac¬ 
terise  the  lower,  upper,  and  convex  powerdomains  (see,  e.g.,  [10,27]).  This 
leads  to  nine  distinct  variations  of  applicative  similarity  and  bisimilarity  for 
non-deterministic  programs,  which  collapse  to  just  two  relations  on  determin¬ 
istic  programs. 

For  the  sake  of  brevity,  “applicative”  is  implicit  when  similarity  or  bisimi¬ 
larity  are  used  in  the  sequel.  The  reader  is  also  cautioned  that  terminology  for 
(what  we  call)  similarity  or  bisimilarity  differs  amongst  authors.  We  use  the 
following  conventions:  simulations  and  bisimulations  are  post-fixed  points  of 
a  function;  similarity  and  bisimilarity  are  the  greatest  simulations  and  bisim¬ 
ulations  respectively;  the  prefix  “bi”  refers  to  a  function  on  relations  with  a 
symmetric  image;  mutual  similarity  is  the  greatest  symmetric  relation  con¬ 
tained  in  similarity. 
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The  variants  of  similarity  and  bisimilarity  are  defined  in  terms  of  two  func¬ 
tions  of  binary  relations  on  programs.  For  a  binary  relation  72.  on  programs, 
we  define  binary  relations  on  programs:  (72)ls  and  (72)us-  The  subscripts 
abbreviate  lower  similarity  and  upper  similarity. 

Definition  3.1  Let  72  be  a  binary  relation  on  programs.  The  binary  relations 
(72)ls  and  (72)us  are  defined  by: 

(i)  M,N  e  Expg.  are  related  by  (72)ls  if: 

(a)  a  =  unit;  or 

(b)  a  =  nat  and  3neK  M  n  A  N  n;  or 

(c)  cr  =  Ti  ->  T2  and  VL  G  Exp^^.  (M  L)  72  {N  L);  or 

(d)  a  =  P(r)  and  VMi.M  [Mi]  =>  {3Ni.N  [Ni]  A  Mi  72  iVi). 

(ii)  M,N  e  Expg.  are  related  by  (72)us  if: 

(a)  a  =  unit;  or 

(b)  <T  =  nat  and  3neK  M  iT’^y  n  A  N  n;  or 

(c)  f7  =  Ti  — >■  r2  and  VL  G  Exp^^.  (M  L)  72  (N  L);  or 

(d)  (j  =  P(r)  and  -(M 

{^{N  A  viVi.iv  iy^’^y  [iVi]  =j>  (bMi.m  [Mi]  AMi72iVi)). 

The  functions  (•)Lg  and  (•)us  differ  only  in  their  action  at  computation 
types.  If  the  assumption  that  divergent  behaviour  is  less  than  any  convergent 
behaviour  is  made  explicit,  then  an  immediate  connection  can  be  made  with 
one  of  the  methods  used  to  construct  the  lower  and  upper  powerdomains 
[21,23]. 

We  are  now  in  a  position  to  define  the  nine  variants  of  similarity  and 
bisimilarity.  Six  of  the  relations  are  defined  as  the  greatest  fixed  points  of 
combinations  of  the  functions  defined  above.  However,  it  is  easy  to  verify  by 
induction  that  the  simple  type  system  of  the  computational  lambda-calculus 
ensures  that  the  greatest  fixed  points  of  the  functions  are  also  least  fixed 
points.  The  remaining  relations,  the  mutual  similarities,  are  the  greatest  sym¬ 
metric  relations  contained  in  the  three  similarities. 

Definition  3.2  The  similarity  and  bisimilarity  relations  are  defined  by  (where 
i/72.<^(jR)  denotes  the  greatest  fixed  point  of  0): 


^LS 

def 

i/72.{72)Lg 

~US 

def 

i/72.(72)us 

~CS 

def 

i/72.(72)ls 

n 

{^)us 

—LB 

def 

i/72.(72)Lg 

n 

— UB 

def 

1/72.  (72)  us 

n 

(K°’'>us 

— CB 

i/72.(72)ls 

n 

{R)us  n  (K'»'>S  n  {R"P>a’s 

In  addition,  the  mutual  similarities  ~Lg,  ~cg  are  defined  to  be  the 
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greatest  symmetric  relations  contained  in  <Lg,  <uS)  ~cs  respectively. 
The  names  of  the  relations  are  summarised  in  the  table  below. 


Lower 

Upper 

Convex 

Similarity 

i$LS 

^US 

~cs 

Mutual  Similarity 

— LS 

—US 

— CS 

Bisimilarity 

—LB 

— UB 

— CB 

We  refer  to  the  tutorial  papers  [9,26]  for  the  standard  results  concerning 
similarities  and  bisimilarities;  each  similarity  is  a  preorder;  each  bisimilarity 
and  mutual  similarity  is  an  equivalence;  and  the  program  that  cannot  con¬ 
verge,  fixrr.  X,  is  a  least  element  for  each  of  the  similarities.  In  addition, 
it  is  immediate  from  the  definitions  that  programs  related  by  any  of  the  sim¬ 
ilarities  or  bisimilarities  have  the  same  type. 

Although  the  method  of  definition  of  the  similarities  and  bisimilarities  is 
convenient  for  the  proof  of  compatibility  in  section  4,  it  is  helpful  to  have  the 
unwound  definition  to  mind.  In  the  case  of  convex  bisimilarity  we  have  that, 
if  M  and  N  are  programs  of  the  same  computation  type,  then  M  N  if 
and  only  if: 

(i)  VMi.M  [Ml]  {3Ni.N  [A^i]  A  Mi  ~cb  ^i);  and 

(ii)  ViVi.AT  [ATi]  (3Mi.M  [Ml]  A  Mi  ~cb  ^i):  and 

(iii)  N 

Lower  bisimilarity  follows  the  same  pattern  as  convex  bisimilarity  with  the 
exception  that  condition  (iii)  is  dropped.  We  omit  the  unwinding  of  upper 
bisimilarity,  but  note  that  it  identifies  programs  that  can  diverge,  and  that 
it  does  not  identify  a  program  that  can  diverge  with  one  that  does  not.  For 
example,  the  program  in  example  2.4  is  identified  with  ?N  by  lower  similarity 
and  bisimilarity,  but  not  by  the  upper  and  convex  variants  of  similarity  and 
bisimilarity. 

Lemmas  3.3  and  3.4  state  elementary  properties  of,  and  relationships  be¬ 
tween,  the  different  variants. 

Lemma  3.3  Erratic  choice  is  the  join  operation  for  ^ls,  and  the  meet  opera¬ 
tion  for  at  the  computation  types,  i.e.,  for  all  programs  of  a  computation 
type  L,  M,  N: 

(i)  (L  or  M)  <Ls  N  if  and  only  if  L  <ls  N  and  M  <ls  AT, 

(ii)  L  <us  (M  or  N)  if  and  only  if  L  <ug  M  and  L  <ug  N. 

Lemma  3.4  The  following  inclusions  hold: 

(i)  ;$CS  ^  ^LS  -CS  ^  -LS  ^  -us.  ~CB  ^  -LB  ^  ^UB- 

(ii)  ^LB  ^  -LS.  -UB  ^  -US.  -CB  ^  “CS- 
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Fig.  4.  Inclusions  between  Similarities  and  Bisimilarities 

Example  3.5  The  following  examples  demonstrate  the  strictness  of  the  in¬ 
clusions  of  lemma  3.4-‘ 

(i)  For  any  program  M,  (fior  [[M]])  and  (flor  [(flor  [M])])  are  related  by: 

(~lb  n  (-LS -us).  (^LS  n  <us);  ^ut  not  by:  <cs,  ^cs>  <^nd 

— CB-  this  we  derive: 

(flor  [[M]])  ((<Lsn<us)\<cs)  {^or  [(fior  [M])]) 

{nor  [[M]])  ((^LS  -us)  \ -cs)  (^o''  l^])]) 

(fior  [[M]])  ((— LB  ^  — ub)  \  — cb)  (^01'  [(i^or  [M])]) 

(ii)  If  M  (<LS  \;$Ls)  then  {[M]  or  [N])  (c^ls  \-lb)  W]-  Similarly,  if 

we  have  M  (;<us  \  ~us)  ^ .  then  [M]  (—us  \  — ub)  ([-^1  W])-  '^he  as¬ 

signment  M  =  n  and  N  =  [★]  satisfies  both  of  the  hypotheses.  Finally,  if 

^  (~cs  \  ~cs)  ^  (^cs  \  ~cs)  hf’  then: 

{[L]  or([M]  or  [AT]))  (~cs  \-cb)  (W  or  W]) 

A  suitable  assignment  is:  L  =  n,  M  =  (flor  [★]),  and  N  =  [■*■]. 

Figure  4  depicts  the  relationships  between  the  similarities  and  bisimilarities 
described  in  lemma  3.4  and  example  3.5.  Every  edge  denotes  a  strict  inclusion. 

As  previously  stated,  the  similarities  and  bisimilarities  collapse  to  a  sim¬ 
ilarity  preorder  and  a  bisimilarity  equivalence  respectively  if  we  remove  ?N 
from  the  programming  language.  It  is  easy  to  construct  programs,  see  exam¬ 
ple  3.6,  that  demonstrate  that  the  introduction  of  finite  non-determinism  is 
not  conservative  for  any  of  the  similarities  and  bisimilarities.  Perhaps  more 
surprising  is  that  the  upper  and  convex  variants  of  similarity  and  bisimilarity 
are  not  conservatively  extended  when  finite  non-determinism  is  extended  to 
countable  non-determinism.  This  is  discussed  in  example  3.7. 

Example  3.6  The  following  programs  cannot  be  distinguished  by  application 
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to  deterministic  programs: 

h  \x  ;  P(nat).lety  <^=  xin  [plus(i/,y)] :  P(nat)  P(nat) 
h  Ax  :  P(nat).lety  xinlet^;  xin  [plus  (y,  2:)]  :  P(nat)  -»  P(nat) 

They  can  be  distinguished  by  applying  them  to  a  non- deterministic  program 
such  as  (0  or  1),  in  which  case  the  second  program  may  converge  to  [plus  (0, 1)]. 

Example  3.7  The  following  programs  cannot  be  distinguished  by  application 
to  finitely  non- deterministic  programs: 

h  A"x.  [a]  :  P(nat)  — >•  P(unit) 
h  /  O  :  P(nat)  P(unit) 

where  f  xy^=  let 2:  •<=  y  in  if  (leq  {z,  x))  then  [★]  else  f  zy 

(the  definition  of  f  is  intended  to  be  formalised  as  in  example  2.2).  The 
programs  can  be  distinguished  by  the  upper  and  convex  similarities  and  bisimi¬ 
larities  by  applying  them  to  ?N.  The  first  program  is  a  strict  constant  function. 
The  second  program  has  only  one  convergent  behaviour,  will  fail  to  terminate 
if  its  argument  does,  but,  in  addition,  may  diverge  if  it  is  possible  to  read  an 
infinite,  strictly  increasing  sequence  of  numbers  from  its  argument. 

The  similarity  and  bisimilarity  relations  extend  in  a  standard  way  to  rela¬ 
tions  on  arbitrary  typed  terms  by  open  extension.  In  general,  the  open  exten¬ 
sion  of  a  relation  on  programs  TZ,  denoted  relates  typed  terms  F  h  M  :  cr 
and  r  h  A/” :  (T  if  r  =  xi  :  Ti, . . . ,  Xn  ;  r„  and 


ilF[Z/i/xi] . . .  [Z/n/^n]  ^  -A^[Z'i/xi] . . .  [iv,i/x,i] 
for  all  Li  G  Exp^^ , . . . ,  Z/„  G  Exp^^ . 

4  Compatibility 

In  this  section  we  sketch  a  proof  that  the  open  extensions  of  the  similarities 
and  bisimilarities  of  section  3  are  compatible  for  the  programming  language. 
A  relation  'll  is  compatible  for  a  language  if  it  is  preserved  by  every  constructor 
6  of  the  language,  that  is,  IZ  is  closed  under  the  rule: 

MiUNi  ...  MnUNn 

e{Mu...,Mn)ne{Nu...,Nn) 

where  the  arity  of  6  is  n.  Compatibility  is  of  fundamental  importance  because 
it  is  a  prerequisite  for  compositional  reasoning. 

Howe  [11]  describes  a  method  using  a  congruence  candidate  for  proving 
the  compatibility  of  lower  similarity.  In  later  work,  Howe  [12]  and  Ong  [21] 
extend  the  method  to  convex  bisimilarity  and  convex  similarity  respectively. 
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Unfortunately,  other  methods  (see,  e.g.,  [1,25,5])  that  have  been  used  to  prove 
compatibility  of  similarity  for  deterministic  programming  languages  do  not 
seem  to  be  applicable  here:  there  are  difficulties  with  interpreting  ?N  in  the 
upper  and  convex  powerdomains,  and  the  methods  based  on  syntactic  logical 
relations  use  syntactic  continuity  (see  section  5)  to  establish  the  fundamental 
property.  Moreover,  the  compatibility  of  mutual  similarity  does  not  entail  the 
compatibility  of  bisimilarity  for  a  non-deterministic  programming  language. 

We  now  sketch  Howe  and  Ong’s  extension  of  Howe’s  congruence  candidate 
method. 

(i)  The  congruence  candidate  TZ*  of  a  binary  relation  IZ  on  programs  (which 
will  range  over  the  variants  of  similarity  and  bisimilarity)  is  an  inductively 
defined  binary  relation  on  (potentially)  open,  well-typed  terms.  It  is 
the  least  relation  closed  under  the  following  rule,  where  9  ranges  over 
constructors  of  the  language,  including  variables,  and  the  arity  of  6  is  n: 

LilZ*  Ml  . . .  LnlZ*  Mn  9{Mi,...  ,Mn)n°N 
e{Lu...,Ln)TZ*N 

(ii)  If  72^  is  a  preorder,  then  the  congruence  candidate  1Z°  satisfies: 

(a)  n°  cn\ 

(b)  C  TZ\ 

(c)  TZ*  is  compatible. 

(d)  Ml  TZ*  Ni  A  Ms  TZ*  N2  Mi  [Ms/x]  TZ*  Ni  [N2/X] . 

(iii)  If  7^  is  a  preorder,  the  restriction  to  programs  TZ*q  of  the  congruence 
candidate  TZ*  is  a  post-fixed  point  of  (•)Lg  or  (•)us  if  TZ  is: 

(a)  TZ  C  (72^)ls  — TZq  C  (7?.5)ls. 

(b)  TZ  C  (7?.)us  TZq  C  (72.o)us- 

This  is  established  by  induction  on  the  derivation  of  a  may  convergence 
judgement  for  (a),  and  on  a  natural  number  that  is  derived  from  a  pro¬ 
gram  that  cannot  diverge  for  (b) — although  a  problem  is  discussed  below. 

(iv)  When  TZ  is  lower,  upper,  or  convex  similarity,  we  deduce  by  co-induction 
that  TZq  C  TZ,  and  thus  TZ*  =72.°.  Consequently,  the  open  extensions  of 
lower,  upper,  and  convex  similarity  are  compatible,  because  the  respec¬ 
tive  congruence  candidates  are.  Compatibility  of  the  mutual  similarities 
follows  immediately. 

(v)  The  final  step  is  to  deduce  that  each  of  the  bisimilarities  are  compatible. 
If  TZ  is  an  equivalence,  it  can  be  shown  using  induction  that  TZ*  C  72*+“^, 
where  72*'^  denotes  the  transitive  closure  of  the  congruence  candidate  of 
72,  which  is  compatible  by  an  easy  induction.  Hence,  TZ*^  C  TZ*^°'^,  so 
TZ*'^  is  symmetric.  In  addition,  we  can  derive  from  (iii)  that: 

(a)  72  C  (72>ls  TZ*q^  C  (723)^8  ^  (^S''>ls- 

(b)  72  C  (72)us  — ^  ^  (^o)us  —  (^o^)us- 

As  in  (iv),  co-induction  can  be  used  to  show  that  TZ*'^  coincides  with  72, 
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K  {K  G  Can) 

M  M  N 

uop  (M)  bop  (M,  N) 

T  1 1  must  ]\T  1 1  must 

-  (L  n  +  1  and  n  G  N) 

if  L  then  M  else  N 

T  II must  AT  II must 

^.1 - -  (LiT^^O) 

if  L  then  M  else  N 

(Mr- Ax. MO 

M  {N[Mi/x]  I  M  [Ml]} 

lot^  ^  Min  A/’  Jlmust 


let  a;  4=  Min  iV  Jj-""'®* 

M[fixa;.  M/x] 
fixx.M 

Fig.  5.  Must  Convergence 


?Nf 


must 


when  Tt  is  lower,  upper,  or  convex  bisimilarity.  Therefore,  the  bisimilar¬ 
ities  are  compatible. 

It  is  worth  noting  that  the  method  also  works  for  recursive  types  and  in 
the  absence  of  types,  and  that  the  use  of  the  computational  lambda-calculus 
means  that  we  do  not  need  to  use  disjoint  sets  of  call-by-name  and  call-by¬ 
value  variables  as  in  [12,21]. 

However,  we  have  glossed  over  a  problem  with  (iii)(b).  Howe  and  Ong 
assigned  natural  numbers  to  programs  that  cannot  diverge  and  that  have 
only  finitely  many  convergent  behaviours.  For  this  reason,  their  proofs  only 
hold  for  programming  languages  with  finite  non-determinism. 

The  method  can  be  extended  to  a  language  with  countable  non-determinism 
by  using  induction  on  the  derivation  of  a  must  convergence  judgement.  The 
rules  for  must  convergence  appear  in  figure  5.  Using  induction  on  these 
rules,  the  proof  works  smoothly  for  both  finite  and  countable  non-determinism. 
The  only  problem  is,  how  do  we  know  that,  for  any  program  M,  M  if 
and  only  if  M  This  turns  out  to  be  trivial,  because  the  complement  of 

the  greatest  fixed  point  of  a  monotone  function  on  a  complete  boolean  lattice 
is  the  least  fixed  point  of  another  monotone  function  that  can  be  derived  from 
the  original  function  (see  [2]),  and  the  must  convergence  rules  in  figure  5  are 
derived  in  this  way  from  the  may  divergence  rules  in  figure  3. 

Theorem  4.1  The  lower,  upper,  and  convex  variants  of  similarity,  mutual 
similarity,  and  bisimilarity  are  compatible. 
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5  Convergence  and  Continuity 

This  section  describes  unwinding  properties  of  recursive  programs  with  re¬ 
spect  to  may  and  must  convergence,  and  examines  related  syntactic  continuity 
properties  of  the  lower  and  upper  similarities.  The  first  part  covers  may  con¬ 
vergence  and  lower  similarity,  and  the  second  part  covers  must  convergence 
and  upper  similarity.  The  latter  includes  an  analysis  of  the  heights,  measured 
by  ordinals,  of  derivation  trees  associated  to  must  convergence  judgements. 

Well-typed  terms  of  the  form  fix  a:.  M,  henceforth  called  fixed  point  expres¬ 
sions,  satisfy  a  finite  unwinding  property  with  respect  to  may  convergence:  for 
any  fixed  point  expression  fixa:.  M,  let  fix^”^a;.  M  denote  the  n’th  unwinding, 
defined  inductively  by: 

fix(%.M  =  n 

fix("+^)x.  M  =  M[fix(")a:.  M/x] 

Then,  whenever  x  :  P((7)  h  M  :  P(cr)  and  x  :  P(cr)  I-  iV  :  r, 

iV[fixa;.  M/x]  if  and  only  if  3n  <  u).  7V[fix^"^a;.  M/x]  (1) 

where  L  if  and  only  if  3K.  L  K.  The  proof  is  the  same  as  for 
deterministic  languages  (see,  e.g.,  [15,26]). 

A  related  result  is  a  so-called  syntactic  continuity  property  of  lower  simi¬ 
larity  on  deterministic  programs:  for  terms  N  and  M,  as  above,  and  L  e  Exp^., 

A/’[fixa;.  M/x]  <ls  L  if  and  only  if  Vn  <  lo.  Ar[fix  M/x]  <Lg  L  (2) 

See  [14,26].  But  syntactic  continuity  is  not  valid,  in  general,  for  non-deterministic 
programs: 

Example  5.1  Recall  the  program  M  fix  a:.  ([0]  or  let  y  a:in  [plus(y,  1)]), 

from  example  2.4.  Let  N  ^  let  x  in  [let  y  in  [if  leq  {x,  y)  then  x  else  y]] . 
Then,  for  every  finite  unwinding  of  M,  is  lower  similar  to  N. 

But  [M]  and  N  are  not  lower  similar.  (The  calculations  are  straightforward.) 

We  now  turn  our  attention  to  must  convergence.  First,  consider  finitely 
non-deterministic  programs  where  non-determinism  only  occurs  in  the  form  of 
binary  erratic  choice.  In  this  case,  the  derivation  trees  of  the  must  convergence 
judgements  introduced  in  section  4  are  only  finitely  branching.  As  a  result, 
the  finite  unwinding  property  of  fixed  point  expressions  (1)  also  holds  with 
respect  to  must  convergence.  Moreover,  upper  similarity  satisfies  the  syntactic 
continuity  property  (2)  (see  [15]). 

In  general,  must  convergence  derivation  trees  of  programs  involving  count¬ 
able  choice  are  countably  branching.  The  complexity  of  the  trees  can  be 
measured  by  assigning  ordinals  to  them  in  the  usual  way  (a  node  is  assigned 
the  supremum  of  the  successors  of  the  ordinals  associated  with  its  children. 
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see,  e.g.,  [20]),  and  this  allows  us  to  give  an  ordinal  bound  to  the  induction 
used  in  the  proof  of  theorem  4.1.  The  bound  is  simply  the  supremum  of  the 
ordinals  associated  to  the  derivations  of  must  convergence  judgements.  Fol¬ 
lowing  work  of  Apt  and  Plotkin  [3],  the  bound  turns  out  to  be  the  least 
non-recursive  ordinal.  We  recall  the  definition  of  recursive  ordinals  below,  but 
refer  the  reader  to  [29,20]  for  detailed  accounts  of  the  recursive  ordinals. 

Definition  5.2  An  ordinal  a  is  recursive  if  there  exists  a  decidable  order  on 
the  natural  numbers  that  is  order-isomorphic  to  a. 

We  first  demonstrate  that  for  each  recursive  ordinal  a  there  is  a  program 
that  cannot  diverge,  and  that  has  a  must  convergence  derivation  tree  with 
height  at  least  a.  Since  a  is  a  recursive  ordinal,  and  it  can  be  verified  that 
every  partial  recursive  function  can  be  defined  in  the  programming  language, 
there  is  a  program  :  nat  nat  ->•  P(nat)  that  does  not  diverge  on  any 
input,  and  the  relation  that  it  represents  is  order-isomorphic  to  a.  Now  we 
also  need  to  construct  a  program  slow  that  accepts  as  arguments  a  program 
representing  an  order  on  natural  numbers,  and  a  natural  number.  It  then 
“counts  down”  from  the  given  number  until  it  reaches  a  minimal  element,  at 
which  point  it  converges  to  [★].  The  type  of  the  program  is: 

h  slow  :  (nat  nat  ->•  P(nat))  -4-  nat  -4  P(unit) 

It  is  intended  that  the  numeric  argument,  say  n,  is  the  code,  with  respect  to 
the  coding  used  by  M^,  of  an  ordinal  ^  <  a,  and  that  the  height  of  the  deriva¬ 
tion  tree  of  (slow  n)  is  at  least  /3.  Intuitively,  the  must  convergence 
derivation  tree  for  this  program  should  contain  as  sub-trees  the  derivation 
trees  for  (slow Mam)  where  m  codes  an  ordinal  strictly  less  than  p. 

The  expressive  power  of  ?N  can  be  used  to  do  this:  by  choosing  any  natural 
number  we  are  choosing  the  code  of  any  ordinal  strictly  less  than  a.  The 
decidability  of  the  order  on  codes  of  ordinals  strictly  less  than  a  allows  us 
to  then  discard  codes  of  ordinals  that  are  greater  than  or  equal  to  p.  The 
following  definition  accomplishes  this: 

slow  /  a;  let  y  4=?N  in  let  z  4=  /  y  a:  in  if  z  then  (slow  /  y)  else  [4r] 

Then,  for  each  recursive  ordinal  a  represented  by  Ma,  we  can  define  a  program 
with  a  must  convergence  derivation  tree  of  height  a: 

let  a;  <^=?N  in  slow  Ma  x  (3) 

In  the  other  direction  we  have  to  show  that  the  ordinal  height  of  a  must 
convergence  derivation  tree  is  always  recursive.  Suppose  that  M  is  a  program 
that  must  converge,  and  that  has  a  derivation  tree  with  height  a.  The  ordinals 
strictly  less  than  o;  are  represented  by  paths  in  the  tree  that  start  at  the  root 
of  the  tree,  i.e.,  at  M,  together  with  annotations  for  the  may  convergence 
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side-conditions.  With  the  side  conditions  given,  it  is  decidable  whether  an 
arbitrary  path  is  a  valid  path  from  M  by  checking  each  component  of  the 
path  against  the  rule  schema  of  figure  5.  With  a  suitable  encoding  of  paths 
in  the  tree  as  sequences  of  natural  numbers,  the  derivation  tree  of  M 
is  a  recursive  tree,  and  then  the  Kleene-Brouwer  order  on  paths  of  the  tree 
is  both  decidable  and  order-isomorphic  to  an  ordinal  greater  than  or  equal 
to  a.  We  refer  the  reader  to  [20]  for  the  definition  of  recursive  trees  and  the 
Kleene-Brouwer  order. 

In  general,  fixed  point  expressions  in  countably  non-deterministic  programs 
do  not  satisfy  a  finite  unwinding  property  with  respect  to  must  convergence, 
because  of  the  possibly  transfinite  heights  of  derivation  trees;  and  the  syntac¬ 
tic  continuity  property  of  upper  similarity  is  invalid.  For  instance,  if  a  > 
the  program  (3)  is  a  counterexample  to  both  the  finite  unwinding  and  syntac¬ 
tic  continuity  properties.  It  is,  however,  possible  to  formulate  an  unwinding 
property  for  must  convergence  that  holds  for  countable  non-determinism  by 
progressing  to  transfinite  unwindings: 

iV[fixa;.  M/x]  if  and  only  if  3a  <  M/x]  iT""'  (4) 

In  order  to  make  sense  of  this  assertion,  we  need  to  define  the  transfinite  un¬ 
windings  and  their  must  convergence  behaviour.  We  extend  the  syntax  with 
new  terms  M,  for  all  recursive  limit  ordinals  A,  with  the  same  typing 

rule  as  for  ordinary  fixed  point  expressions.  Arbitrary  recursive  unwindings 
fix^^^x.  M,  for  a  <  are  defined  if  we  let  fix^^^x.  M  f2,  as  above,  and, 

inductively,  fix(“+^^x.  M  M[fix(“)x.  M/x],  for  all  o;  <  Next,  the  defi¬ 
nition  of  must  convergence  has  to  be  extended  to  the  new  terms.  Intuitively, 
we  want  the  following  rule  which  expresses  that  the  must  convergence  at  re¬ 
cursive  limit  ordinals  is  the  best  of  all  the  must  convergence  behaviours  at 
smaller  ordinals: 


fix(“)x.  M 
fix  Wx.  M 


(a  <  A  < 


But,  since  the  definition  of  must  convergence  in  figure  5  depends  on  may 
convergence,  it  would  be  necessary  to  extend  the  may  convergence  relation  on 
terms  of  computation  type  to  the  new  terms  as  well,  and  it  it  is  not  clear  how 
to  do  this.  We  get  around  this  obstacle  by  giving  a  self-contained  definition  of 
must  convergence  at  computation  types  without  reference  to  may  convergence. 
This  can  be  achieved  by  means  of  either  a  “structurally  inductive”  definition 
of  the  must  convergence  predicate,  M  in  the  style  of  Pitts  [24]  or  an 

inductively  defined  must  convergence  relation,  M  U,  between  terms  M 
and  sets  of  canonical  terms  U.  We  sketch  the  second  solution  here.  If  M  is 
a  term  in  the  original  language,  the  meaning  of  M  1].*““®*  U  is  that  M  must 
converge  and  that  14  is  the  set  of  canonical  terms  that  M  may  converge  to. 
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For  example, 


K  {K}  {K  e  Can)  ?N  {[n]  |n  G  N} 

A  rule  for  let  can  be  given  without  reference  to  may  convergence: 

M  U  {N[Mifx]  Vmi  I  [Ml]  G  U} 
let  a:  ^  M  in  AT  (J  {Vm^  \  [Mi]  G  U} 

The  remaining  rules  are  straightforward  and  make  no  reference  to  may  con¬ 
vergence  at  computation  types.  The  must  convergence  relation  is  extended 
to  the  new  terms  for  transfinite  unwindings  of  fixed  point  expressions  by  the 
rule: 


M  U 

fix  ^^x.M  U 


(a  <  A  < 


The  analysis  of  the  definition  of  the  must  convergence  predicate  in  figure  5 
shows  that  the  closure  ordinal  of  the  rules  for  the  must  convergence  relation 
is  also  a;f^.  The  must  convergence  predicate,  M  is  obtained  from  the 

must  convergence  relation  as  M  ^  3  W.  M  lA.  This  concludes  the 
definition  of  the  must  convergence  behaviour  of  the  transfinite  unwindings  of 
fixed  point  expressions.  The  proof  of  (4)  is  by  induction  on  the  derivation  of 
the  must  convergence  judgment. 

The  definition  of  the  upper  similarity  from  section  3  can  be  extended  to 
programs  with  occurrences  of  transfinite  unwindings  of  fixed  point  expressions, 
by  extending  (7^)us  to  relate  programs  M,N  e  Exp„  at  computation  types 
a  —  P(r)  if 

W.M  U  (3V.Ar  V  A  ViVi  G  V.BMi  G  U.Mi  Tl  Nx) 

The  extension  of  upper  similarity  is  obtained  as  the  greatest  fixed  point  of 
the  extended  definition  of  the  function  (•)us-  It  is  compatible  with  respect 
to  the  extended  language.  The  compatibility  proof  for  upper  similarity  from 
section  4  carries  over  if  the  induction  is  now  conducted  on  the  derivation  of 
M  U. 

We  ask  two  questions  about  the  extension  of  upper  similarity  to  the  ex¬ 
tended  language.  First,  is  it  a  conservative  extension,  i.e.,  does  it  include  the 
upper  similarity  relation  defined  in  section  3  for  the  original  language?  Second, 
does  it  enjoy  a  transfinite  syntactic  continuity  property?  If  both  are  answered 
aflSrmatively,  we  get  a  useful  induction  principle  for  reasoning  about  fixed 
point  expressions  with  respect  to  upper  similarity  in  the  original  language. 
The  two  questions  are  left  as  open  problems. 
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6  Beyond  Countable  Choice 


We  have  described  two  forms  of  non-determinism:  the  construct  that  we  have 
taken  as  primitive  ?N,  and  binary  erratic  choice.  In  this  section,  we  outline 
two  other  possibilities  that  have  been  proposed  in  the  literature. 

The  first  is  based  on  the  observation  that  binary  erratic  choice  has  precisely 
the  same  expressiveness  as  a  new  choice  construct  ?  {0, 1}  that  may  converge  to 
either  [0]  or  [1],  but  cannot  diverge.  It  is  natural  to  ask  whether  other  forms  of 
non-determinism  can  be  obtained  in  a  similar  way,  e.g.,  if  X  is  a  non-empty  set 
of  natural  numbers,  then  what  is  the  expressiveness  of  a  choice  construct  ?X 
that  may  converge  to  [n],  for  any  n  £  X,  but  cannot  diverge?  It  turns  out  that 
choice  constructs  for  countably  infinite  sets  of  natural  numbers  are  not  always 
equally  expressive,  because  Apt  and  Plotkin  [3]  show  that  exactly  the  choice 
constructs  for  non-empty,  recursively  enumerable  sets  of  natural  numbers  can 
be  defined  from  ?N.  This  suggests  that  classifying  non-deterministic  programs 
by  the  cardinality  of  their  convergent  behaviour  is  misleading. 

However,  classification  is  not  the  only  issue  affected  by  the  result  of  Apt 
and  Plotkin.  In  the  light  of  example  3.7,  it  is  of  interest  to  know  whether 
the  presence  of  additional  forms  of  non-determinism  further  alters  the  upper 
and  convex  variants  of  similarity  and  bisimilarity.  If  this  is  the  case,  then  a 
denotational  model  of  non-determinism  that  can  interpret  sets  of  natural  num¬ 
bers  that  are  not  recursively  enumerable  will  discriminate  more  than  mutual 
similarity  (or  bisimilarity)  for  a  programming  language  with  only  ?N. 

In  order  to  study  these  problems,  the  programming  language  given  here 
can  be  extended  with  additional  choice  constructs  of  the  form  described  above. 
The  proofs  of  compatibility  sketched  in  section  4  readily  extend  to  more  gen¬ 
eral  forms  of  “erratic”  non-determinism  [23].  Roscoe  [30]  studies  similar  non- 
deterministic  choice  constructs  in  an  extension  of  CSP. 

McCarthy’s  ambiguous  choice  operator  exhibits  a  very  different  form  of 
non-determinism.  The  ambiguous  choice  of  two  programs  has  a  natural,  fair 
(also  known  as  dove-tailing)  implementation:  run  both  programs  in  parallel, 
and  return  the  value  of  the  first  to  converge.  The  ambiguous  choice  of  two 
programs  can  converge  to  any  value  that  the  programs  can  converge  to,  but 
only  diverges  when  both  programs  can  diverge. 

Moran  [18]  studies  a  functional  programming  language  extended  with  am¬ 
biguous  choice  and  proves  that  lower  similarity  is  compatible  for  the  language. 
An  example  is  given  there  that  shows  that  convex  similarity  cannot  be  com¬ 
patible  in  the  presence  of  ambiguous  choice.  Similar  examples  can  be  used  to 
show  that  upper  similarity  and  bisimilarity  also  fail  to  be  compatible.  How¬ 
ever,  the  compatibility  of  convex  bisimilarity  in  the  presence  of  ambiguous 
choice  is  an  open  problem.  The  method  described  in  section  4  is  not  immedi¬ 
ately  applicable  because  it  would  imply  the  compatibility  of  convex  similarity. 
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7  Conclusion 

We  have  defined  a  simply-typed  functional  programming  language  with  an 
operator  that  can  converge  to  any  natural  number,  and  have  introduced  nine 
compatible  relations  on  programs.  The  relations  are  lower,  upper,  and  con¬ 
vex  variants  of  applicative  similarity  and  bisimilarity.  Although  some  of  the 
relations  have  been  studied  individually  in  the  literature,  we  have  emphasised 
that  they  can  be  constructed  using  only  two  functions,  and  that  this  affords  a 
natural  structure  to  the  proofs  of  compatibility.  In  addition,  we  have  mapped 
the  inclusions  between  the  relations,  and  have  given  characteristic  examples 
of  the  differences  between  them. 

Although  the  programming  language  is  based  on  the  computational  lambda- 
calculus  and  non-determinism  is  restricted  to  computation  types,  the  examples 
can  be  modified  for  programming  languages  with  non-determinism  at  function 
or  product  types  (with  the  assumption  that  convergence  is  observable  at  those 
types).  We  also  note  that  the  mechanism  for  creating  and  composing  com¬ 
putations  in  the  computational  lambda-calculus  provides  an  alternative,  with 
the  same  expressive  power,  to  using  both  call-by-name  and  call-by-value  ab¬ 
stractions  to  control  the  resolution  of  non-determinism. 

A  different,  interesting  example  demonstrates  that  the  upper  and  convex 
variants  of  similarity  and  bisimilarity  are  sensitive  to  whether  finite  or  count¬ 
able  non-determinism  is  present  in  the  programming  language,  i.e.,  countable 
non-determinism  can  be  used  to  distinguish  programs  of  function  type  that 
cannot  be  distinguished  by  finitely  non-deterministic  programs. 

Previous  proofs  of  compatibility  have  been  restricted  to  languages  with 
finite  non-determinism.  We  have  extended  them  to  a  programming  language 
with  countable  non-determinism  by  using  a  relationship  between  least  and 
greatest  fixed  points  in  complete  boolean  lattices  to  transform  a  co-inductively 
defined  may  divergence  predicate  into  an  inductively  defined  must  convergence 
predicate.  The  supremum  of  the  ordinal  heights  of  the  must  convergence 
derivation  trees  is  the  least  non-recursive  ordinal 

In  this  paper  we  have  concentrated  on  operational  models  based  on  co- 
inductively  defined  similarity  and  bisimilarity  relations.  It  may  be  argued 
that  the  resulting  models  are  finer-grained  than  is  warranted  by  reasonable 
notions  of  observation.  An  alternative  is  to  operate  with  Morris-style  contex¬ 
tual  approximation  preorders  and  equivalence  relations  which  are  naturally 
defined  on  the  basis  of  the  may  and  must  convergence  predicates  [13,15].  The 
compatibility  of  the  similarity  and  bisimilarity  relations  considered  here  im¬ 
plies  that  they  are  all  contained  in  corresponding  contextual  relations.  The 
inclusions  are  strict,  for  different  reasons  [15].  For  instance,  the  failure  of 
syntactic  continuity  in  example  5.1  distinguishes  lower  similarity  from  may 
contextual  approximation  which  does  satisfy  the  syntactic  continuity  prop¬ 
erty  (2)  for  arbitrary  non-deterministic  programs.  Lower  and  upper  similarity 
are  used  as  auxiliary  relations  in  [13]  to  reason  about  contextual  equivalences 
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for  the  operationally-defined  specification  language  of  action  semantics,  action 
notation,  which  features  countable  non-determinism. 
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Abstract 

Studies  of  the  mathematical  properties  of  impredicatively  polymorphic  types  have 
for  the  most  part  focused  on  the  polymorphic  lambda  calculus  of  Girard-Reynolds, 
which  is  a  calculus  of  total  polymorphic  functions.  This  paper  considers  polymor¬ 
phic  types  from  a  functional  programming  perspective,  where  the  partialness  arising 
from  the  presence  of  fixpoint  recursion  complicates  the  nature  of  potentially  infinite 
(4azy’)  datatypes.  An  operationally-based  approach  to  Reynolds’  notion  of  rela¬ 
tional  parametricity  is  developed  for  an  extension  of  Plotkin’s  PCF  with  V-types 
and  lazy  lists.  The  resulting  logical  relation  is  shown  to  be  a  useful  tool  for  proving 
properties  of  polymorphic  types  up  to  a  notion  of  operational  equivalence  based  on 
Morris-style  contextual  equivalence. 


1  Introduction 

‘It  turns  out  that  virtually  any  basic  type  of  interest  can  be  encoded  within  F2 
[polymorphic  lambda  calculus].  Similarly,  product  types,  sum  types,  existential 
types,  and  some  recursive  types,  can  be  encoded  within  F2:  polymorphism  has  an 
amazing  expressive  power.  ’ 


Cardelli  [6,  page  2225] 

It  is  a  widely  held  view — typified  by  the  above  quotation — that  the  poly¬ 
morphic  lambda  calculus  (PLC)  of  Girard  and  Reynolds  [10,32]  plays  a  foun¬ 
dational  role  for  the  statics  (type  systems)  of  functional  programming  lan¬ 
guages  analogous  to  the  one  played  by  the  untyped  lambda  calculus  for  the 
dynamics  of  such  languages.  The  technical  justification  for  this  view  rests  on 
the  encoding  of  a  wide  class  of  datatype  constructions  as  PLC  types:  see  for 
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example  [5,34]  and  [11,  Chapter  11].  However,  these  results  cannot  just  be  ap¬ 
plied  ‘off  the  shelf’  to  deduce  properties  of  functional  programming  languages 
equipped  with  polymorphic  types.  This  is  because  PLC  is  a  theory  of  total 
polymorphic  functions — a  consequence  of  the  fact  that  /^-reduction  of  typeable 
PLC  terms  is  strongly  normalising  [10].  On  the  other  hand,  functional  pro¬ 
gramming  languages  typically  feature  various  mechanisms  for  making  general 
forms  of  recursive  definitions,  both  at  the  level  of  expressions  and  at  the  level 
of  types.  The  first  kind  of  definition  of  course  entails  the  presence  of  ‘partial’ 
expressions,  i.e.  ones  whose  evaluation  does  not  terminate.  And  then  the  sec¬ 
ond  kind  of  definition  may  throw  up  types  whose  values  involve  partiality  in 
complicated  ways,  through  the  use  of  non-strict  constructors.  Can  such  ‘lazy’ 
datatypes  be  encoded  with  combinations  of  function-  and  V-types? 

A  specific  example  may  help  to  bring  this  question  into  sharper  focus.  Con¬ 
sider  the  type  num  list  of  lazy  lists  of  numbers  in  a  non-strict  functional  pro¬ 
gramming  language,  such  as  Haskell  (www.haskell.org/report/).  The  canon¬ 
ical  forms  of  this  type  are  the  nil-list,  nil,  and  cons-expressions,  H:T,  where 
the  head  H  (of  type  num)  and  the  tail  T  (of  type  num  list  again)  are  not 
necessarily  in  canonical  form  (and  therefore  their  evaluation  may  not  termi¬ 
nate).  Thus  expressions  of  this  type  can  represent  finite  lists  (such  as  0:nil), 
properly  infinite  lists  (such  as  £  =  0:£),  or  ‘partial’  lists  (such  as  0:f2,  where 
is  a  divergent  expression  of  type  num  list).  Suppose  now  that  the  language 
is  augmented  with  V-types.  (We  consider  why  one  might  want  to  do  so  in  a 
moment.)  In  PLC,  the  type 

L{t)  V  a  (a -)■  (t ->■  a ->■  a)  ->■  a)  (a  not  free  in  r) 

encodes  finite  r-lists — ^in  the  sense  that  the  closed  |d-normal  forms  of  L(t)  are 
in  bijection  with  finite  lists  of  closed  yd-normal  forms  of  type  r.  But  what  is 
the  situation  in  the  functional  programming  language?  Can  uses  of  the  lazy 
list  type  num  list  always  be  replaced  by  the  polymorphic  type  L{num)?  More 
precisely,  are  num  list  and  L{num)  ‘operationally  isomorphic’,  in  the  sense 
that  there  are  functions  in  the  language  from  num  list  to  L{num)  and  back 
again  which  are  mutually  inverse  up  to  some  reasonable  notion  of  operational 
equivalence  of  expressions?  Or  is  num  list  operationally  isomorphic  to  some 
some  other  pure  polymorphic  type,  or  to  no  such  type? 

The  reader  will  not  find  the  answer  to  such  questions  in  the  literature,  as 
far  as  I  know.  Partly  this  is  because  it  is  hard  to  construct  denotational  mod¬ 
els  of  both  impredicative  polymorphism  and  fixpoint  recursion.  Such  models 
do  exist  (see  [7,8]  for  one  style  of  model  and  [2]  for  another),  but  there  is  not 
much  in  the  way  of  useful  analysis  of  the  properties  of  polymorphic  types  in 
them.  On  the  other  hand  for  pure  PLC,  Reynolds’  notion  of  relational  para- 
metricity  [33,20]  turns  out  to  provide  a  very  powerful  tool  for  such  an  analysis. 
There  are  models  of  PLC  supporting  a  relationally  parametric  structure  [3], 
and  in  such  models  polymorphic  encodings  of  datatype  constructions  have 
strong  properties,  indeed  have  category-theoretic  universal  properties  charac- 
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terising  the  constructions  uniquely  up  to  isomorphism  [16,17,1,30].  Can  one 
extend  this  relational  approach  to  encompass  fixpoint  recursion?  Unpublished 
work  of  Plotkin  [29]  indicates  that  one  can.  Here  we  show  that  a  relatively 
simple,  syntactic  approach  is  possible. 

Should  one  care?  Well,  for  one  thing  the  results  presented  here  provide 
a  basis  for  obtaining  some  ‘free  theorems’  [35]  up  to  operational  equivalence 
(and  modulo  some  restrictions  to  do  with  strictness)  in  languages  like  ML  and 
Haskell  that  combine  higher  order  functions,  fixpoint  recursion  and  predicative 
polymorphism.  However,  the  power  of  the  relational  approach  really  shows 
when  considering  fully  impredicative  V-types.  Since  the  type  reconstruction 
problem  is  undecidable  in  this  case  [36]  and  explicit  labelling  with  type  infor¬ 
mation  is  considered  cumbersome,  most  higher  order  typed  languages  meant 
for  human  programmers  eschew  fully  impredicative  polymorphism.  However, 
it  seems  that  impredicative  polymorphism  may  be  a  useful  feature  of  explicitly 
typed  intermediate  languages  in  compilers  [14,23].  And  undoubtedly  there  is 
foundational  interest  in  knowing,  in  the  presence  of  fixpoint  recursion,  to  what 
extent  various  kinds  of  type  can  be  reduced  to  pure  polymorphic  types. 

As  Wadler  [35,  Sec.  7]  and  Plotkin  [29]  point  out,  extending  relational 
parametricity  to  cope  with  fixpoint  recursion  seems  to  necessitate  working 
not  with  arbitrary  relations,  but  with  ones  that  are  at  least  admissible  in  the 
domain-theoretic  sense,  i.e.  that  are  bottom-relating  and  closed  under  taking 
limits  of  chains  of  related  approximations.  However,  in  this  paper  a  rela¬ 
tional  framework  for  polymorphism  and  fixpoint  recursion  is  developed  which 
is  based  upon  operational  rather  than  denotational  semantics.  This  allows 
one  to  avoid  some  of  the  complexities  of  the  domain- theoretic  approach.  In 
particular,  it  turns  out  that  questions  of  admissibility  of  relations  only  have 
to  be  treated  implicitly,  via  an  operationally-defined  closure  operator.  This  is 
perhaps  the  main  technical  contribution  of  the  paper.  As  a  result  one  obtains 
a  straightforward  and  apparently  quite  powerful  method  for  proving  proper¬ 
ties  of  Morris-style  contextual  equivalence  of  expressions  and  types  involving 
impredicative  polymorphism  and  fixpoint  recursion;  and  one  which  is  based 
only  upon  the  syntax  and  operational  semantics  of  the  language.  (See  [25,26] 
for  previous  results  of  this  kind.) 

The  plan  of  the  paper  is  as  follows.  In  the  next  section  we  introduce 
PGF'^,  an  extension  of  PCF  [28]  with  lazy  lists  and  V-types  which  will  serve 
as  the  vehicle  for  examining  the  issues  raised  above.  In  Sec.  3  we  define  a 
notion  of  observational  congruence  for  PCF^  expressions:  it  is  equivalent  to 
a  Morris-style  contextual  equivalence  based  upon  observing  convergence  of 
evaluation  in  all  contexts  of  list-type  (but  not  of  function-  or  V-type).  Sec.  4 
presents  our  syntactic  version  of  relational  parametricity.  An  action  of  the 
PCF'^  types  on  binary  relations  between  PCF'^  expressions  (of  the  same  closed 
type)  is  defined.  This  gives  rise  to  a  certain  binary  logical  relation  which  is 
shown  to  characterise  PCF"^  observational  congruence  (Theorem  4.15).  Sec.  5 
shows  how  the  logical  relation  can  be  used  to  prove  basic  properties  of  PCF^ 
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observational  congruence  (such  as  various  extensionality  properties)  and  to 
prove  observational  isomorphisms  between  types.  We  show,  for  example,  that 
in  PCF'^  it  is  indeed  the  case  that  a  list  is  observationally  isomorphic  to  the 
pure  polymorphic  type  V a'  {a' a')  a') .  Finally,  Sec.  6  considers 
some  directions  in  which  the  results  presented  here  might  usefully  be  extended. 


2  Combining  PCF  and  Impredicative  Polymorphism 


We  will  make  use  of  a  small  programming  language,  PCF'^,  which  is  a  relative 
of  that  veteran  of  studies  in  programming  languages,  PCF  [28].  Recall  that 
PCF  is  a  simply  typed,  call-by-name  lambda  calculus  equipped  with  fixpoint 
recursion  and  some  basic  operations  on  ground  types  of  natural  numbers  and 
booleans.  To  this  we  add  V-types  from  the  Girard-Reynolds  polymorphic 
lambda  calculus  and  a  type  constructor  for  lists.  For  reasons  of  parsimony  we 
do  without  the  ground  types  of  natural  numbers  and  booleans,  because  the 
role  they  play  in  the  theory  can  be  taken  by  the  list  types.  So  the  PCF^  types 
are  given  by 


r  ::=  a  type  variable 

I  T  list  list  type 

I  T  —^T  function  type 

I  V  O'  (r)  V-type 

and  the  PCF^  terms  are  given  by 


M 


X 

nilr 

M::M 

case  M  of  nil  ^  M  \  x::x=^  M 
Xx  :t  (M) 

MM 

Aa{M) 

M  T 


variable 
empty  list 
non-empty  list 
case  expression 
function  abstraction 
function  application 
type  generalisation 
type  specialisation 


I  fix(M)  fixpoint  recursion. 

Here  a  and  x  range  over  disjoint  countably  infinite  sets  TyVar  and  Var  of 
type  variables  and  variables,  respectively.  The  constructions 

Vq'(— )  caseMof  nil=^M' I  a; ::  (— )  Aa::T(— )  Aq!(— ) 

are  binders  and  we  will  identify  types  and  terms  up  to  renaming  of  bound 
variables  and  bound  type  variables.  We  write  ftv{e)  for  the  finite  set  of  free 
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r,x:rl-a::T  PI-  nilr  :  r  list 


T\-H:t  Ti-T-.Tlist 
r  h  i?  ::  T  :  T  list 


ry-  L:ti  list  T\-  Ml  :t2  T,h:Ti,t  :ti  list  h  M2  :  r2 
r  h  case  L  of  nil  =>  Mi  \h::t^  M2  :  T2 


r,  X  :  Ti  h  M  :  T2  F  h  P  :  ti  ^  r2  F  I-  ^  :  ti 

F  h  A  X  ;  Ti  (M)  :  Ti  ^  T2  F  h  F  ^  :  r2 

a,FhM:T  FhG:Va(ri)  rhF:r-»T 

F  h  A  a  (M)  :  Va  (r)  F  h  G  r2  :  ri  [T2/a]  F  h  fix(F)  :  r 


Fig.  1.  PCF'^  type  assignment  relation 

type  variables  of  an  expression  e  (be  it  a  type  or  a  term)  and  fv{M)  for  the 
finite  set  of  free  variables  of  a  term  M.  A  type  r  is  closed  if  ftv{T)  =  0; 
whereas  a  term  M  is  closed  if  fv{M)  =  0,  whether  or  not  it  also  has  free  type 
variables.  The  result  of  substituting  a  type  r  for  all  free  occurrences  of  a  type 
variable  a  in  e  (a  type  or  a  term)  will  be  denoted  e[r/a].  Similarly,  M\M' /x\ 
denotes  the  result  of  substituting  a  term  M'  for  all  free  occurrences  of  the 
variable  x  in  M. 

We  are  only  interested  in  terms  that  can  be  assigned  types.  We  use  a 
typing  judgement  of  the  form  T  M  :  r  where 

•  the  typing  environment  F  is  a  pair  A,  A  with  A  a  finite  subset  of  Ty  Var  and 
A  a  function  defined  on  a  finite  subset  dom{A)  of  Var  and  mapping  each 
X  €  dom{A)  to  a  type  with  free  type  variables  in  A] 

•  M  is  a  term  with  ftv{M)  C  A  and  fv{M)  C  dom{Ay, 

•  r  is  a  type  with  ftv{T)  C  A. 

Then  the  PCF'^  type  assignment  relation  consists  of  all  such  judgements  in¬ 
ductively  defined  by  the  axioms  and  rules  in  Fig.  1 — all  of  which  are  quite 
standard.  In  the  figure,  the  notation  F,  a: :  r  indicates  the  typing  environment 
obtained  from  the  typing  environment  F  =  A,  A  by  properly  extending  the 
function  A  by  mapping  x  ^  dom{A)  to  r.  Similarly,  a,  F  is  the  typing  en¬ 
vironment  obtained  by  properly  extending  A  with  an  a  ^  A.  Note  that  the 
explicit  type  information  included  in  the  syntax  of  terms  means  that,  given  F 
and  M,  there  is  at  most  one  r  for  which  F  h  M  :  r  holds. 

We  write  Typ  for  the  set  of  closed  PCF'^  types.  Given  r  €  Typ,  we  write 
Termir)  for  the  set  of  PCF^  terms  M  for  which  0  h  M  :  r  is  derivable  from 
the  axioms  and  rules  in  Fig.  1. 

We  give  the  operational  semantics  of  PGF^  in  terms  of  an  inductively 
defined  relation  of  evaluation.  It  takes  the  form  M  C,  where  M  and  C  are 
closed  terms  of  the  same  closed  type  (i.e.  M,  C  €  Term{T)  for  some  r  €  Typ) 
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C  JJ-  C  {C  canonical) 

LI)  nil,  Mii^C  L^g::T  M2[g//i,r/t]  ^  C 

(caseLofnil=>' Ml  |  h::t=^M2)  ■d-C'  (case  L  of  nil  Mi  |  h::t=>M2)  ii-C 

Fii.\x:T{M)  M{Alx]i).C  GOAa(M)  M[r/a](lG  Ffix(F)d-C 
FA^C  Gt^C  fix(F)  (1 C 


Fig.  2.  PCF'^  evaluation  relation 

and  where  C  is  in  canonical  form: 

(7::=  m\r\M  ::M  \Xx:t{M)  \Aa{M). 

The  evaluation  relation  is  inductively  defined  by  the  axiom  and  rules  in  Fig.  2. 
Note  that  function  application  is  given  a  call-by-name  semantics  and  that  the 
evaluation  rule  for  type  specialisations,  G  r,  is  dictated  by  our  choice  of  canon¬ 
ical  form  at  V-types — we  choose  not  to  evaluate  ‘under  the  A’.  Evaluation  is 
deterministic:  given  M,  there  is  at  most  one  C  for  which  M  ij-  C  holds;  and 
of  course  the  rule  for  fix  entails  that  there  may  be  no  such  C. 

3  Observational  Congruence 

Recall  that  two  terms  of  a  programming  language  are  regarded  as  contextually 
equivalent  if  they  are  interchangeable  in  any  program  without  affecting  the 
observable  behaviour  of  the  program  upon  execution.  Of  course,  to  make  this 
a  precise  notion  one  has  to  choose  what  constitutes  an  executable  program  and 
what  behaviour  should  be  observable.  For  PCF,  Plotkin  [28]  chooses  ‘program’ 
to  mean  ‘closed  term  of  ground  type’  and  the  observable  behaviour  of  such  a 
program  to  be  the  constant  (integer  or  boolean)  to  which  it  evaluates,  if  any. 
Since  we  have  replaced  ground  types  with  list  types,  here  we  take  a  program 
to  be  a  closed  term  of  list  type  and  we  observe  whether  or  not  it  evaluates  to 
nil. 

Thus  given  P  h  Mi  :  r  and  F  h  M2  :  r  in  PCF'^',  we  can  say  that  the 
terms  Mi  and  M2  are  contextually  equivalent,  and  write  P  h  Mi  =ctx  M2  :  r , 
if  for  any  context  Ad[— ]  for  which  Ai[Mi],  Ai[M2]  €  Term{T'  list)  for  some 
r'  e  Typ,  it  is  the  case  that 

Ad  [Ml]  1)  nil,'  Ad  [M2]  -[)-  nil,'. 

As  usual,  a  context  Ad[-]  means  a  PCF^  term  with  a  subterm  replaced  by 
the  placeholder  and  then  Ad[M']  indicates  the  term  that  results  from 
replacing  the  placeholder  with  the  term  M'.  This  is  a  textual  substitution 
which  may  well  involve  capture  of  free  variables  in  M'  by  binders  in  Ad[— ]. 
So,  unlike  terms,  contexts  are  not  identified  up  to  renaming  of  bound  variables. 
Although  this  might  seem  like  a  minor  syntactic  matter,  it  is  an  indication 
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T,x:t\-  x£  x:t  Ph  nilr  £  nil^  :  r  list 


T\-H£H'-.t  T\-T  £T'  -.Tlist 
V\-{H::T)£{H' ■.■.T'):Tli$t 


T\-  L£  L’  -.Tilist  V\-  Mi£  M[:t2  T  ,h  :  :  n  list  \- M2  £  M'^  :  T2 

r  h  (case  L  of  nil  Mi  |  h::t=^  M2)  £  (case  L'  of  nil  ^  M[  \  h::t^  M^)  '■  T2 

T,x:ti\- M  £  M' :t2  T  h  F  £  F' :  n  ^  T2  TbA£A':Ti 

r  h  Ax  :  Ti  (M)  £  Xx  :ti  (M')  :ti  ->T2  T  \-  {F  A)  £  {F'  A')  :  T2 

a,ri-M£:M':r  V  h  G  £  G' :'i  a{n) 

r  I-  Aa{M)  £  Aa(M')  :Va(T)  P  h  (GT2)  £  {G'  T2)  :  Ti[r2/a] 

T\- F  £  F'  -.T-^T 
P  I-  fix(F)  £  fix(M')  :  T 


Fig.  3.  Compatibility  properties 


a,PhMi:M':Ti 

P[r2/a]  h  M[T2/a]  £  M'[t2/q!]  :  rx[r2/a] 


P,  X  :  Ti  I-  M  f  M'  :  r2 
P  t-  M[iV/x]  £  M>[N I x]  :  T2 


if  P  I-  AT :  n 


Fig.  4.  Substitutivity  properties 

that  the  notion  of  ‘context’  occurring  in  the  above  definition  of  contextual 
equivalence  is  rather  too  concrete.  Perhaps  a  better  indication  is  the  fact  that 
the  substitutivity  property  of  PCF^  contextual  equivalence 

r,  a; :  Ti  h  M  =ctx  ’•  '^2  ^  P  h  iV  :  Ti 
r  h  M{N/x]  =ctx  M'\N/x\  :  ra 

is  by  no  means  an  immediate  consequence  of  the  above  definition  of  =ctx-  This 
is  because  M[Nlx]  is  not  of  the  form  for  some  context  A4iv[— ]  (uni¬ 

formly  in  M).  Nevertheless,  we  can  regard  M[N/x]  as  a  use  of  M  ‘in  context’, 
or  in  other  words,  it  is  reasonable  to  demand  that  the  above  substitutivity 
property  holds  of  a  notion  of  PCF'^  contextual  equivalence  by  definition. 

For  these  reasons,  in  the  rest  of  this  section  we  develop  a  slightly  more 
abstract  treatment  of  PCF'^  contextual  equivalence  that  avoids  explicit  use  of 
contexts  (following  [12,18]).  In  fact,  this  approach  also  makes  it  easier  to  state 
and  prove  the  fundamental  properties  of  the  logical  relation  to  be  defined  in 
the  next  section. 
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Definition  3.1  Suppose  5  is  a  set  of  4-tuples  (F,  M,  M',t)  satisfying 

(1)  r  h  M  5  M' :  r  (F  h  M  :  r  &  r  h  M' :  r) 

where  we  write  F  h  M  £  M' :  r  instead  of  (F,  M,  M' ,  t)  £  S. 

(i)  S  is  compatible  if  it  is  closed  under  the  axioms  and  rules  in  Fig.  3.  It  is 
substitutive  if  it  is  closed  under  the  rules  in  Fig.  4.  (All  these  axioms  and 
rules  are  intended  to  apply  only  to  4-tuples  satisfying  the  well-formedness 
condition  (1)). 

(ii)  Note  that  compatible  relations  are  automatically  reflexive.  A  PCF^  pre¬ 
congruence  is  a  compatible,  substitutive  relation  which  is  also  transitive.  A 
PCF'^  congruence  is  a  precongruence  which  is  also  symmetric. 

(iii)  S  is  adequate  if  for  all  closed  types  r  €  Typ  and  closed  terms  M,  M'  6 
Term{T  list) 

m  h  M  £  M' :  T  list  ^  (M  .(I- nil^  M' ^  nil^). 

Theorem  3.2  (PCF'^  observational  congruence)  There  is  a  largest  ade¬ 
quate  PCF^  congruence  relation.  We  call  it  PCF^  observational  congruence 
and  write  it  as  =obs- 

Proof.  Obviously  the  intersection  of  any  collection  of  PCF^  congruence  re¬ 
lations  is  another  such.  So  the  PCF'^  congruence  relations  form  a  complete 
lattice  when  ordered  by  subset  inclusion.  Slightly  less  obviously,  but  for  quite 
general  reasons,  the  join  in  this  complete  lattice  of  some  congruences  Si  is 
given  by  ((J^  Si)*,  the  reflexive-transitive  closure  of  the  set-theoretic  union  of 
the  relations.  ^  In  particular,  the  join  of  all  the  adequate  congruences  is  given 
by  the  reflexive-transitive  closure  of  their  union.  But  this  is  again  adequate, 
because  adequate  relations  clearly  are  closed  under  the  operations  of  union 
and  reflexive-transitive  closure.  Fi 

PCF'^  observational  congruence,  =obs)  is  indeed  equivalent  to  the  con¬ 
textual  equivalence  =ctx  which  we  mentioned  at  the  start  of  this  section.^ 
However,  this  ‘context  free’  version  is  technically  more  convenient  when  it 
comes  to  relating  contextual  equivalence  to  the  logical  relation  introduced  in 
the  next  section.  For  more  results  about  ‘context  free’  characterisations  of 
contextual  equivalence,  see  [19,  Section  3.7]. 

We  conclude  this  section  with  some  examples  of  properties  of  PCF'^  types 
up  to  observational  congruence.  It  does  not  seem  easy  to  prove  such  properties 
directly  from  the  deflnition  of  observational  congruence  (or  using  the  more 


^  To  see  this,  note  that  in  the  presence  of  reflexivity  and  transitivity,  the  compatibility 
conditions  in  Fig.  3  involving  two  hypotheses  can  each  be  replaced  by  two  rules  involving 
only  single  hypotheses:  and  of  course  the  union  of  some  relations  closed  under  single¬ 
hypothesis  rules  (and  the  reflexive-transitive  closure  of  such  a  relation)  is  another  such. 

®  The  only  difiicult  part  of  the  proof  of  coincidence  of  =ctx  and  =obs  is  the  fact  that  =ctx 
is  closed  under  the  rules  in  Fig.  4,  the  substitutivity  properties.  This  can  be  proved  as  a 
corollary  of  the  properties  of  the  logical  relation  of  Sec.  4,  but  we  do  not  do  so  here. 
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concrete  notion  of  contextual  equivalence).  The  logical  relation  of  the  next 
section  will  provide  the  means  to  prove  such  properties. 

In  the  case  of  closed  terms  of  closed  type,  we  just  write  Mi  =obs  M2  :  r 
for  0  h  Ml  =obs  M2  :  r. 

Example  3.3  (Polymorphic  null  type)  Consider  the  type 

null  *=  Vq:(q!). 

In  PCF'^  there  is  a  closed  term  of  this  type,  namely  A  a  (fix(A  x  : 

a  (x))).  This  is  a  ‘polymorphic  bottom’  since  for  each  r  €  Typ  it  is  not  hard 
to  see  that  r  diverges,  i.e.  that  there  is  no  C  for  which  r  JJ-  C  holds.  In 
fact,  up  to  observational  congruence,  f2  is  the  only  closed  term  of  type  null. 
In  other  words,  we  claim  that  for  all  G  G  Term{nult),  one  has  G  =obs  •  null. 

Example  3.4  (Polymorphic  unit  type)  Consider  the  type 

unit  Va(a:— >q:). 

As  well  as  the  ‘bottom’  term  Q  unit,  this  type  contains  the  polymorphic 
identity  function  Aa{Xx  :  a{x)).  But  that  is  all:  we  claim  that  if  G  £ 
Term{unii),  then  either  G  =obs  {^unit)  :  unit  or  G  =obs  AQ!(Aa;  :  01  (x))  : 
unit. 

Example  3.5  (Polymorphic  lists)  Consider  the  polymorphic  list  type 
L{a)  V a'  (o'  — >  (o  — >  a'  — >■  a')  — >  a'). 

Define  terms  I  and  J  as  follows: 

/  A  O'  (fix  {Xi :  a  list  ->  L{a)  {X£  :  a  list  ( 

Aa*  (Xx' :  a'  {X  f  :  a a'  a'  { 

case^of  nil  re'  |  h  ::t=^  f  h{it  a' x'  f )))))))) 

Aa{Xp  :  L{a)  {p  {a  list)  {N a)  {C oc))) 

where  N  AQ!(nila)  and  G  *=  Aa{Xh  :  a(Xt  :  a  list  {h  ::  t))).  Then  I 
and  J  are  closed  terms  of  types  V  a  (a  list  L{a))  and  V  a  {L{a)  — >•  a  list) 
respectively.  We  claim  that  these  terms  constitute  an  isomorphism  between 
a  list  and  L(q;)  up  to  observational  congruence,  polymorphically  in  a.  In  other 
words,  the  following  observational  congruences  hold: 

a,  £  :  a  list  \-  J  a  {I  a  £)  =obs  £  ■  o;  list 
a,  g  :  L{a)\- 1 a{Jag)  =ohs  9  ■  L{oi). 

4  Syntactical  Relational  Parametricity 

We  aim  to  characterise  PCF^  observational  congruence  (defined  in  Theo¬ 
rem  3.2)  in  terms  of  a  binary  ‘logical  relation’  incorporating  a  notion  of  re¬ 
lational  parametricity  analogous  to  that  introduced  by  Reynolds  [33]  for  the 
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(3)  A.,(r-)  r, 

(4)  At  list  {f}  =  ur{{l  +  Ar{i^  X  r)^^) 

(5)  At^t'(^  =  AT(f)^AT^(fO 

(6)  Ava(r)(0  =  Vr(AT(r‘^^,f)) 


Note 

(4)  uses  Definitions  4.9  and  4.7;  (5)  uses  Definition  4.2;  (6)  uses  Definitions  4.3  and  4.7. 


Fig.  5.  Definition  of  the  logical  relation  A 

pure  polymorphic  lambda  calculus.  The  logical  relation  is  parameterised  by 
term-relations. 

Definition  4.1  (Term-relations)  Given  closed  PCF'^  types  r,  r'  G  Typ, 
we  write  Rel{T,T')  for  the  set  of  subsets  of  Term{T)  x  Term{T'). 

Each  open  type  t(q'i,  . . . ,  an)  gives  rise  to  a  function  mapping  tuples  of 
term-relations  to  term-relations: 

(2)  ri  €  Rel{Ti,T[), . . .  ,r„  G  i?e/(r„,r')  i-4  AT(f)  G  /2e/(T(f),r(f')). 

This  ‘action’  of  PCF^  types  on  term-relations  is  defined  by  induction  on  the 
structure  of  the  type  r,  as  in  Fig.  5.  The  definition  makes  use  of  various 
operations  on  term-relations,  associated  with  the  PCF'^  type  constructors, 
which  will  be  explained  below.  When  r  is  a  closed  type,  (2)  amounts  to 
specifying  a  certain  term-relation  Ar  €  Rel{T,T)  and  this  will  turn  out  to 
coincide  with  observational  congruence; 

Ml  =ctx  M2  :  r  4^  (Ml,  M2)  G  A^  (Mi,  M2  G  rerm(r)). 

This,  together  with  the  definition  of  A  at  V-types  is  what  permits  us  to  deduce 
results  like  those  in  Examples  3.3-3.5  (see  Secs  5. 2-5. 5). 

The  definition  of  in  terms  of  A^i  and  A^j  in  Fig.  5  uses  the  following 

operation  on  term-relations,  characteristic  of  the  notion  of  ‘logical  relation’ 
(cf.  [27]). 

Definition  4.2  (Action  of  — >  on  term-relations)  Given  ri  G  i?e/(ri,r[) 
and  r2  €  Rel{T2, T2),  we  define  ri  — >•  r2  €  Rel{Ti  ->  T2,  r]  ->  r^)  by; 

{F,  F')  G  ri  r2  ^  V  {A,  A')  G  ri  {{F  A,  F'  A')  G  r2). 

Turning  next  to  V-types,  consider  the  following  operation. 

Definition  4.3  (Action  of  V  on  term-relations)  Let  ri  and  r]  be  PCF^ 
types  with  at  most  a  single  free  type  variable,  a  say.  Suppose  i?  is  a  function 
mapping  term-relations  r  G  Rel{r2,T!^  (s^ny  T2,T2  G  Typ)  to  term-relations 
R{r)  G  i2e/(Ti[T2/o'],  t([t2/q:]).  Then  we  can  form  a  term-relation  V r  (R{r))  G 
i?el(V a  (ti),  Vo  (r[))  as  follows; 
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T  Id  :t 


r  h  S  o  (case  —  of  nil  ^  Mi  \  h::t^  M2)  •  t  list  — «  t'‘ 


{r  t-  Ml  :  t' 


list  h  M2  :  t' 


r  h  5  :  r' 


r  1-  5  o  (—  A)  :  (r  ->  r')  — o  r" 


if  r  h  ^  :  T 


r  h  S' :  r'[T/a]  — o  r" 
r  h  S  o  (-  t)  :  Va  (r')  — »  r" 


Fig.  6.  Typing  frame  stacks 
(G,G')€\/riR{r))  U 

Vr2,T2  e  Typi^r  €  Rel{T2,T2)  {{Gt2,G't2)  €  i2(r))). 

From  [33]  one  might  expect  the  definition  of  Ava  (n) (0  to  be  V r  (A^  {r,  fj). 
This  will  not  do  for  PCF'^  because  of  the  presence  of  fixpoint  recursion.  For 
then  we  would  have  Ava(a)  =  Vr(r)  =  0  (since  we  can  instantiate  the  pa¬ 
rameter  r  with  the  empty  relation).  But  then  Ay  a  (a)  cannot  coincide  with 
=obs  as  we  desire,  because  the  latter  is  not  empty:  from  Example  3.3  we  have 
O  =obs  :  Va  (a).  As  this  example  may  indicate,  we  will  have  to  restrict  the 
parameterising  relations  in  the  definition  of  Ava(T)  at  least  to  be  ‘admissible 
for  fixpoint  induction’,  in  some  way.  In  domain  theory,  a  subset  of  a  domain 
is  said  to  be  admissible  if  it  contains  the  least  element  of  the  domain  and  is 
closed  under  taking  least  upper  bounds  of  chains  in  the  domain.  It  is  perfectly 
possible  to  make  use  of  a  direct,  syntactic  version  of  this  notion  by  considering 
term-relations  that  are  closed  under  certain  syntactically  definable  chains  and 
their  limits,  e.g.  those  generated  by  the  finite  unfoldings  of  a  fixpoint  term,  or 
by  syntactically  definable  projection  functions.  See  [4]  for  an  example  of  this 
approach  to  ‘syntactic  admissibility’.  Here  we  take  a  more  indirect  approach, 
already  present  implicitly  in  [26].  It  enables  us  to  obtain  the  necessary  ad¬ 
missibility  properties  as  a  corollary  of  a  construction  that  we  need  anyway  in 
order  to  build  sufficient  properties  of  evaluation  into  the  logical  relation  for  it 
to  characterise  observational  congruence.  The  key  idea  is  to  consider  relations 
between  PCF^  evaluation  contexts  [9] — those  contexts  M  [— ]  with  a  single  oc¬ 
currence  of  the  placeholder,  in  the  position  where  the  next  subexpression 
will  be  evaluated.  To  aid  analysis  of  the  termination  relation  M  ij.  nilr,  we 
use  the  following  reformulation  of  evaluation  contexts  as  stacks  of  ‘evaluation 
frames’  (cf.  [15]  and  [26,  Sec.  3]). 

Definition  4.4  (Frame  Stacks)  The  grammar  for  PCF'^  frame  stacks  is 

S  Id  \SoF 

where  F  ranges  over  frames: 

F  ::=  (case  — of  nil=^M  I  X ::  x=^M)  |  {— M)  \  (— t). 

We  use  the  judgement  F  h  5  :  r  — o  r'  to  indicate  the  argument  and  result 
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type  of  a  frame  stack.  Here  F  is  a  typing  environment,  as  defined  in  Sec.  2,  and 
we  assume  similar  well-formedness  conditions  as  there  (free  variables  and  free 
type  variables  of  all  expressions  in  the  judgement  are  listed  in  F).  The  axiom 
and  rules  inductively  defining  this  judgement  are  given  in  Fig.  6.  Unlike  PCF'^ 
terms,  we  have  not  included  explicit  type  information  in  the  syntax  of  frame 
stacks.  For  example.  Id  is  not  tagged  with  a  type.  However,  it  is  not  hard  to 
see  that,  given  F,  S,  and  r,  there  is  at  most  one  r'  for  which  F  h  5  :  r  -o  r' 
holds.  This  property  is  enough  for  our  purposes,  since  the  argument  type  of 
a  frame  stack  will  always  be  supplied  in  any  particular  situation  in  which  we 
use  it. 

Definition  4.5  Given  closed  PCF'^  types  r,r'  G  Typ,  we  write  Stack 
for  the  set  of  frame  stacks  S  for  which  0  h  5  :  r  -o  r'  is  derivable  from  the 
axiom  and  rules  in  Fig.  6. 

The  analogue  for  frame  stacks  of  the  operation  of  filling  the  hole  of  an 
evaluation  context  with  a  term  is  given  by  the  operation  S,M  S@Mj  of 
applying  a  frame  stack  to  term.  It  is  defined  by  induction  on  the  length  of  the 
stack: 

Id@M  =  M 

(S  o  F)@M  =  S@{F[M/-]) 

where  F[M/—]  is  the  term  that  results  from  replacing  ’  by  M  in  the  frame 
F.  Note  that  if  5  G  Stack{T,T')  and  M  G  Term{T),  then  S@M  G  Termir'). 

Theorem  4.6  (A  structural  induction  principle  for  termination) 

Given  a  closed  PCF^  term  M  of  list  type,  M  G  Term{T  list)  say,  write  M  i)-  to 
mean  that  M  fl-  nilj  is  derivable  from  the  axiom  and  rules  for  evaluation  given 
in  Fig.  2.  Then  for  all  r,  r'  G  Typ,  M  e  Term{r)  and  S  G  Stack (t,  P  list)  we 
have 

^  St  M 

where  the  relation  (— )  t  (— )  is  inductively  defined  by  the  axiom  and  rules  in 
Fig.  7.  If  St  M  holds  we  say  that  S  and  M  are  coterminate. 

The  proof  of  this  theorem  is  quite  straightforward  and  is  omitted.  Not 
only  does  the  —  t  —  relation  facilitate  inductive  proofs  involving  termination, 
but  also  it  is  the  key  to  our  syntactic  treatment  of  admissibility,  as  we  now 
explain.  Given  a  closed  PCF^  type  r  G  Typ,  define 

TermJ{r)^  Stack{T,T' list). 

r'eTyp 

We  write  Rel^  {t,  t')  for  the  set  of  subsets  of  Term^{T)  x  Term^{T)  and  refer  to 
such  subsets  as  stack-relations.  Using  the  (— )  t  (— )  relation  from  Theorem  4.6 
we  can  manufacture  a  stack-relation  from  a  term-relation  and  vice  versa,  as 
follows. 


12 


Pitts 


St  Ml 

d  T  nilr  - ^ - ; — 

S  o  (case  —  of  nil  Mi  |  /i M2)  t  nil^ 

Sr  M2[H/h,T/t] 

S  o  (case  —  of  nil  =>■  Mi  \  h::t^  M2)  T  H  ::T 

S  T  M[A/x]  S  T  M[r/a] 

5o  (-^)  T  A®  :  t(M)  5o(— r)TAa(M) 

S  o  (case  —  of  nil  Mi  |  h::t=^  M2)  r  L  S  o{—  A)  t  F 
S  T  case  L  of  nil  ^  Mi  \  h::t=^  M2  S  r  F  A 

So{-t)tG  5o(-fix(F))TF 

~sVGt~  S  t  fix(F) 


Fig.  7.  PCF'^  nil-termination  relation 

Definition  4.7  (The  (-)^  operation  on  relations)  Given  any  r,  r'  €  Typ 
and  r  €  Rel{T,T')  define  G  Rel^ {t,t')  by 

(5, S')  er'^  U  y{M,M')er{STM^S'T  M') 

and  given  any  s  G  Rel^{T,T')  define  G  Rel{T,r')  by 

{M,M')  es'^  U\/(S,S')es{STM^S'T  M'). 

Just  from  the  form  of  the  definition  of  the  operations  r  s  (i.e. 

without  using  any  properties  of  the  termination  relation  (— )  t  (— ))  it  is  clear 
that  one  has  a  Galois  connection: 

(7)  riCr2=J>(r2)^C(ri)‘" 

(8)  Si  C  S2  =»  (52)^  C  (si)"’’ 

(9)  rCs'T^^sCr^. 

So  in  particular  r  is  a  closure  operator  for  term-relations,  i.e.  is  order¬ 

preserving,  inflationary  and  idempotent.  Thus  we  say  that  a  term-relation 
r  is  TT-closed  if  r  =  or  equivalently  if  C  r,  or  equivalently  if  r  = 
for  some  stack-relation  s,  or  equivalently  if  r  =  for  some  term- 

relation  t' .  Note  that  the  use  of  (— )^^  in  clause  (6)  of  Fig.  5  means  that  the 
universal  quantification  over  term-relations  in  the  definition  of  Ava(T)(^  is 
being  restricted  to  range  over  TT-closed  relations. 

The  next  result  is  an  indication  that  TT-closed  term-relations  have  appro¬ 
priate  ‘admissibility’  properties. 

Theorem  4.8  (Admissibility  of  TT-closed  term-relations) 

Suppose  r  G  Rel{T,T')  is  rr-dosed.  Then  for  any  F  G  Term{T  -A-  r)  and 
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F'  G  Term{T'  — )■  r')  one  has 

{F,  F')er-^r  (fix(F),  fix(F'))  €  r. 

Proof.  We  use  the  following 

Unwinding  Theorem.  For  any  r  €  Typ,  F  €  Term{T-¥T),  S  €  rerm^(r), 
defining  fir  ani/ (F)  =  Ffix^^\F),  it  is  the  case  that 

5'Tfix(F)  ^  3nG  N(F  Tfix(”H^))- 

This  result,  or  rather  a  slight  generalisation  of  it  using  fixpoint  terms  in  ar¬ 
bitrary  contexts,  can  be  proved  by  relatively  straightforward  inductions  over 
the  definition  of  the  (-)  t  (-)  relation.  We  omit  the  details  (but  see  for 
example  [26,  Theorem  3.2]). 

It  is  not  hard  to  see  that  5  t  fir  does  not  hold  for  any  S  G  TermJ (t) 
(since  evaluation  of  fir  never  terminates).  Thus  (fir, fir')  G  s^,  for  any 
s  G  Rel^ Hence  in  particular  taking  s  =  r^,  we  have 

(fix(°)(F),fix(°)(F'))  G  =  r. 

So  if  (F,  F')  G  r  ->  r,  it  follows  by  induction  on  n  that 

(fix(”)(F),fix(")(F'))  Gr 

holds  for  all  n  G  N.  Finally,  for  any  (S',  S')  G  we  have 

S  T  fix(F)  B  n  G  N  (S  T  fix^”^  (F))  by  the  Unwinding  Theorem 

3  n  G  N  (S'  T  fix(”)  (F'))  since  (fix^")  (F),  fix^")  (F'))  G  r 

and  (S,  S')  G  r'r 

■<=>  S'  T  fix(F')  by  the  Unwinding  Theorem. 

Thus  by  definition  of  (— )^,  (fix(F),fix(F))  G  =  r,  as  required.  □ 

To  complete  the  explanation  of  Fig.  5  we  have  to  define  the  action  of  the 
list  type  constructor  on  term-relations. 

Definition  4.9  (Action  of  (-)  list  on  term-relations) 

Given  r,r'  G  Typ,  ri  G  Rel{T,T')  and  r2  €  Rel(T  list,  t'  list),  define  1  -I-  (ri  x 
r2)  G  Rel{T  list,  r'  list)  by: 

1  +  (ri  X  r2) 

{(nil,,  nil,0}  U  {{H  ::  T,H'  ::  T')  \  {H,  H')  G  n  &  (T,  T')  G  r2}. 

Note  that  the  subset  relation  makes  Relij  list,  r'  list)  into  a  complete  lattice 
and  that,  for  each  ri,  the  function  r2  (1  +  (ri  x  r2))^^  is  monotone.  There¬ 
fore  we  can  form  its  greatest  fixed  point,  vr  {{l-\-  (ri  x  r))^^).  The  function 

ri  G  Rel{T,  r')  i-)-  (ri  x  r))''”'")  G  Rel{T  list,  r'  list) 

is  the  action  of  (— )  list  on  term-relations  used  in  clause  (4)  of  Fig.  5  to  define 
Artist  in  terms  of  A,. 
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Remark  4.10  (List  bisimulations)  When  ri  is  TT-closed,  one  can  give 
an  alternative  characterisation  of  vt{{1  +  (ri  x  r))^^)  which  accords  more 
closely  with  the  characterisation  of  observational  congruence  of  lazy  lists  in 
terms  of  a  notion  of  bisimilarity  to  be  found,  for  example,  in  [24,  Sec.  3].  Given 
ri  G  Rel{T,T'),  call  a  term-relation  r2  €  Rel{T  list,  t'  list)  an  ri-simulation  if 
it  satisfies  that  whenever  (L,  V)  G  then 

•  if  L  JJ.  nil,.,  then  V  IJ-  nilr' 

•  if  L  ^  ::  T,  then  for  some  H'  and  T'  it  is  the  case  that  L'  i)-  H'  ::T'  with 

{H,H)eri  and  (T,r)  Gra- 

Say  that  r2  is  an  ri-bisimulation  if  both  it  and  its  reciprocal  relation  {r2)°^  *= 
{{L,L')  \  {L',L)  G  r2}  are  ri-simulations.  Then  one  can  prove  that  when  ri 
is  TT-closed,  i/r  ((1  -I-  (ri  x  r))^^)  is  the  greatest  ri-bisimulation.  (Moreover 
we  will  see  next  that  the  r\  used  in  Fig.  5,  namely  At-(^,  is  always  TT-closed 
provided  the  term-relations  r  are.) 

The  following  properties  of  TT-closed  term-relations  will  be  needed  below. 

Lemma  If  T2  is  TT-closed,  then  so  is  ri  —y  r2,  for  any  ri.  If  R  is  as 

in  Definition  4-3  and  each  R{r)  is  TT-closed,  then  so  is  Vr  (i?(r)).  Hence 
it  follows  by  induction  on  the  structure  of  PCF'^  types  r  that  Ar(f)  is 
TT-closed  provided  the  term-relations  f  are.  (The  induction  step  for  list 
types  is  automatic,  because  Ariisti^  is  a  term-relation  r  satisfying  r  = 
(1-1- AT(f)  X  (it  is  the  greatest  such)  and  hence  it  is  always  TT-closed.) 

(a)  Kleene  equivalence,  =ki,  is  defined  by: 

Ml  =ki  M2:t  U  VC  (Ml  ^  C  M2  ^  C). 

Then  ifrE  Rel{T,T')  is  a  TT-closed  term-relation,  one  has 

Ml  =ki  M2  :  T  &:  (Ml,  M{)  ^r  Sz  M[  =ki  M^  :  r'  =>  {M2,  M^)  G  r. 

Fig.  5  defines  a  family  of  binary  relations  between  closed  terms.  We  extend 
this  to  a  relation  between  open  terms,  of  the  form  considered  in  Definition  3.1, 
by  considering  closing  substitutions. 

Definition  4.12  (Logical  relation  on  open  terms)  Suppose  F  h  M  :  r 
and  r  h  M'  :  r  hold,  with  F  =  ai, . . . ,  am,  x  :  ti,  . . . , x  :  Tn  say.  Write 

(10)  F  h  M  A  M' :  r 

to  mean; 

given  any  G  Typ  and  ri  G  Rel{ai,a'f)  (for  i  =  1, . . . ,m)  with  each 
TT-closed,  then  for  any  {Nj,Nj)  G  Arj{r)  (for  j  =  1, ...  ,n)  it  is  the  case 

that  {M[a/a,  N/x\,  MY /a,  N'fx])  G  A^(f) 

(The  restriction  to  TT-closed  relations  in  this  definition  accords  with  the  def¬ 
inition  of  A  at  V-types.) 
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Theorem  4.13  (Fundamental  properties  of  the  logical  relation) 

With  A  extended  to  open  terms  as  in  the  previous  definition,  we  have: 

(i)  A  is  compatible  (cf.  Definition  3.1(i)). 

(a)  For  each  closed  type  r  G  Typ  we  have 

{M,  M)  6  Ar  and  {S,  S)  G  (A^)"^ 
for  all  closed  terms  M  G  Term(T)  and  frame  stacks  S  G  rerm^(r). 

(in)  A  is  substitutive  (cf.  Definition  3.1(i)). 

Proof.  For  part  (i),  one  has  to  prove  that  (10)  is  closed  under  the  axioms 
and  rules  in  Fig.  3.  Most  of  these  compatibility  properties  are  immediate 
consequences  of  the  definition  of  A  in  Fig.  5  and  the  way  it  is  extended  to 
open  terms  in  Definition  4.12.  However,  those  for  case,  Xx  :  t(— ),  and 
Aq!(-)  require  Lemma  4.11  together  with  the  following  Kleene  equivalences: 

{Xx:ti{M))A  =ki  M[A/x]:t2 
(A  a  (M))  r2  =ki  M[r2/Q;]  :  n  {r^f a] 
case  nilxi  of  nil  Mi  \  h::t=^  M2  =ki  Mi  :  T2 
caseif  ::rofnil=>Mi  \h::t=^M2  =ki  M2[H/h,Tft]  :  T2. 

The  compatibility  condition  for  fix  follows  from  Theorem  4.8  (together  with 
Lemma  4.11(i)). 

Part  (ii)  follows  from  part  (i).  Since  the  relation  (10)  is  compatible,  it  is 
automatically  reflexive  and  hence  in  particular  (M,  M)  G  A,-  holds.  The  fact 
that  one  also  has  {S,  S)  G  (A,-)^  can  be  proved  by  induction  on  the  structure 
of  S,  using  compatibility  properties  that  form  part  of  the  proof  of  part  (i). 

For  part  (iii),  one  has  to  prove  that  the  relation  (10)  is  closed  under  the  ax¬ 
ioms  and  rules  in  Fig.  4.  The  type-substitutivity  property  reduces  to  showing 
for  open  types  r(a, a)  and  T'{a)  that  A^[T-7a](0  =  Ar(r,  AT'(f)),  for  any  r. 
This  follows  easily  from  the  definition  in  Fig.  5,  by  induction  on  the  structure 
of  r.  Finally,  the  term-substitutivity  property  in  Fig.  4  is  an  easy  conse¬ 
quence  of  Definition  4.12  together  with  the  previously  established  fact  that 
the  relation  (10)  is  reflexive.  D 

The  following  lemma  will  help  us  to  compare  the  logical  relation  with 
observational  congruence. 

Lemma  4.14(i)  If  M  =obs  Af' :  r,  then  for  any  S  G  Term^(r),  S  t  M  holds 
if  and  only  if  S  t  M'  does. 

(ii)  Suppose  r  G  Rel(T,T')  is  TT-closed.  Then 

Ml  =obs  M2  :  r  &:  {Mi,M[)  G  r  &:  M(  =obs  MI^-.t'  =J>  (M2,  M^)  G  r. 

(iii)  A  is  adequate  (cf.  Definition  3.1(iii)). 

Proof.  Recall  that  by  definition  =obs  is  the  largest  compatible,  substitutive, 
and  adequate  relation.  Note  that  the  compatibility  properties  of  =obs  imply 
that  S%M  =obs  5'@M'  :  .list  holds  if  M  =obs  M'  :  r  does.  Therefore  the 
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adequacy  of  =obs  together  with  Theorem  4.6  give  (i).  Part  (ii)  follows  from 
(i)  and  the  assumption  that  r  = 

For  part  (hi),  note  that  by  Theorem  4.13(ii),  for  each  r  €  Typ  we  have 
that  {Id,  Id)  e  (A^Ksi)^-  Thus  if  0  h  MAM'  :  rlist,  i.e.  if  {M,M')  €  Ar lut, 
then  Idr  M  Id  T  M',  and  hence  by  Theorem  4.6,  M  -IJ-  nilr  ^  M’  nilr, 
as  required  for  adequacy. 

Theorem  4.15  Given  T  \-  M  :  t  and  F  h  M'  :  t,  M  and  M'  are  ohserva- 
tionally  congruent  if  and  only  if  they  are  logically  related: 

(11)  r  h  M  =obs  M'  :t  ^  r  h  M  A  M' :  r. 

Proof.  Combining  Lemma  4.11(i),  Definition  4.12  and  Lemma  4.14(ii),  we 
have 

r  1-  Ml  =obs  M2  :t  k  r  h  Ml  A  M(  :  r  k  T  h  M(  =obs  :  r' 
r  h  M2  A  M2  :  T. 

Since  =obs  and  A  are  reflexive  (the  former  by  construction,  the  latter  by 
Theorem  4.13),  we  can  take  Mi  =  M[  =  M2  =  M  and  M2  =  M'  in  (12)  to 
deduce  the  left-to-right  implication  in  (11). 

For  the  converse  implication,  first  note  that  the  compatibility  and  substi- 
tutivity  properties  of  A  (Theorem  4.13)  imply  that  the  equivalence  relation  it 
generates,  (A  U  A^^)*,  is  a  PCF'^  congruence  relation  (cf.  the  proof  of  Theo¬ 
rem  3.2).  Moreover,  (AU  A®^)*  is  adequate,  because  A  is  (Lemma  4.14(iii)). 
Therefore  (AU  A"'')*  is  contained  in  the  largest  adequate  congruence  relation, 
=obs,  and  hence  so  is  A.  FI 

5  Applications  of  Theorem  4.15 

We  give  two  kinds  of  application;  some  general  results  about  PCF'^  observa¬ 
tional  congruence  (such  as  a  ‘ciu’  theorem  and  extensionality  properties)  and 
some  properties  of  particular  PCF'^  types  up  to  =obs  (Examples  3. 3-3.5). 

5.1  A  PCF'^  ‘ciu’  theorem 

Let  us  begin  with  a  version  of  the  ‘closed  instantiations  of  uses’  (ciu)  theorem 
of  Mason  and  Talcott  [22].  It  is  convenient  to  split  this  into  two  parts,  to 
do  with  ‘instantiations’  and  with  ‘uses’  respectively.  The  first  part  reduces 
observational  congruence  of  open  terms  to  that  of  closed  terms  (of  closed 
type),  via  closed  substitution  instances  (which  for  PCF^  involves  substitutions 
both  of  types  and  terms).  Then  the  second  part  permits  us  to  check  the 
observational  congruence  of  two  closed  terms  by  considering  their  termination 
behaviour  just  in  evaluation  contexts  (of  list  type).  Here  we  will  replace 
evaluation  contexts  by  the  equivalent  notion  of  frame  stacks  (Definition  4.4) 
and  use  the  characterisation  of  termination  given  by  Theorem  4.6. 
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Theorem  5.1  {PCF^  ‘ciu’  theorem)  For  each  closed  type  r  G  Typ,  define 
a  binary  relation  on  Term{T)  by 

(12)  M  =ciu  M'  :t  ^  G  Stack{T,  -  list)  {S  r  M  St  M'). 

Then  given  F  h  M  :  r  and  F  h  M'  :  t,  with  F  =  ai, . . . , am,  x  :  ti,  ...  ,x  :  Tn 
say,  we  write 

F  h  M  =ciu  M' :  T 

to  mean  that  for  all  ai  G  Typ  (i  =  and  all  Nj  G  Term{Tj[a /a]) 

(j  =  l,...,n),  it  is  the  case  that  M[a/a, iV/x]  =ciu  M'[a/a,N/x]  :  r[a/a]. 
Then  =ciu  coincides  with  PCF"^  observational  congruence: 

F  h  M  =ciu  M'  :t  ^  F  h  M  =obs  M' :  r. 

Proof.  The  fact  that  =obs  is  contained  in  =ciu  follows  immediately  from  the 
fact  that  =obs  is,  by  definition,  an  adequate  PCF'^'  congruence  relation. 

For  the  converse  implication,  by  Theorem  4.15,  it  suffices  to  show  that  =ciu 
is  contained  in  A.  But  it  is  evident  from  (12)  that  any  TT-closed  term-relation 
respects  =ciu  and  hence  (by  Definition  4.12)  that 

F  h  Ml  =ciu  Ma  :  T  &  F  h  Mi  A  M(  :  r  &  F  h  M(  =„«  :  r' 

F  h  Ma  A  M2  :  r. 

Since  it  is  clear  from  its  definition  that  =ciu  is  reflexive,  and  since  A  is  reflexive 
by  Theorem  4.13,  we  can  take  Mi  =  M(  =  Ma  =  M  and  Ma  =  M'  to  deduce 
that 

ri-M=ciuM':r  =>  F  h  M  A  M' :  r 

as  required. 

Fig.  8  gives  some  basic  properties  of  =obs  (for  simplicity,  stated  just  for 
closed  terms).  All  except  (vii)  are  more  or  less  immediate  consequences  of 
Theorem  5.1.  Property  (vii)  gives  a  coinductive  characterisation  of  observa¬ 
tional  congruence  of  lazy  lists  (cf.  [24],  for  example).  It  follows  by  combining 
Theorem  4.15  with  Remark  4.10.  An  example  of  its  use  occurs  in  the  proof  of 
Example  3.5  (see  Sec.  5.5). 

We  turn  next  to  the  proofs  of  the  properties  of  null,  unit,  and  list  types 
claimed  in  Examples  3.3-3.5. 

5.2  Proof  of  Example  3.3 

Suppose  G  is  a  closed  term  of  type  null  Vq:(q:).  We  have  to  show  that 

G  =obs  ^  '■  null,  where  D  Aa  (fix(Ax  :  a  (x))). 

By  properties  (ii)  and  (vi)  in  Fig.  8,  it  suffices  to  show  for  all  r  G  Typ 
that  Gt  =obs  fix(Ax  :  r  (x))  :  r.  For  this  it  suffices,  by  Theorem  5.1,  to  show 
for  all  S  G  TermJ{T)  that  S  t  (Gt)  does  not  hold,  because  evaluation  of 
fix(A  X  :  r  (x))  does  not  converge. 
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Beta-conversions 

(i)  (Ax  :  Ti  {,M))A  =obs  M[A/x]  :  T2 

(ii)  (Aa(M))T2  =obs  M[r2/a]  ;  ri[r2/a] 

(iii)  (casenilri  ofnil=J'Mi  I /i::t=r>M2)  =obs  Mi  :  r2 
{casBH::Totn\\=^Mi\h-.-.t^M2)  =obs  M2[F/ft,T/t] :  T2. 

(iv)  fix(F)  =obs  Ffix(F):T. 

Extensionality  properties 

(v)  F  =obs  F'  :ti-¥  T2  if  and  only  if  for  all  A  €  Term{Ti),  FA  =obs  F'  A:  T2. 

(vi)  G  =obs  G'  S  Va  (ti)  if  and  only  if  for  all  T2  €  Typ,  Gt2  =obs  G't2  :  ri[r2/a]. 

(vii)  L  =obs  L'  :  rlist  if  and  only  if  {L,L')  G  r  for  some  r  G  Rel{T  list,  t  list)  satisfying  that 
whenever  (M,  M')  G  r  then 

•  M  nilr  if  and  only  if  M'  nil^ 

•  if  M  then  L'  JJ.  H' T'  for  some  H'  and  T'  with  H  =obs  :  r  and  (T,  T')  G  r 

■  a  M'  a.  H'y.T',  then  L  ^  F ::  T  for  some  F  and  T  with  H  =obs  H'  :  r  and  (T,  V)  G  r. 

Eta-conversions 

(viii)  F  =obs  \x  :t{Fx)  :ti-^T2  (where  x  ^  /^(F)). 

(ix)  G  =obs  A  a  (G  a)  :  V  a  (t)  (where  a^ftv{G)). 

(x)  n  (n  T2)  =obs  Ax  :  n  (fl  T2)  (where  fl  A  a  (fix(Ax  :  a  (x)))). 

(xi)  n  (V  a  (t))  =obs  A  a  (n  r). 


Fig.  8.  Some  basic  properties  of  PCF'^  observational  congruence 

From  Theorem  4.13(ii)  we  have  (G,G)  €  Ava(Q)  =  Vr(r^^).  In  other 
words,  for  all  r,  t'  €  Typ  and  r  €  Rel{T,  r')  we  have 

(13)  {GT,Gr')er'^^. 

Given  r,  we  use  (13)  with  r'  =  r  list  and  r  the  one-element  term-relation 

r  {(Qr ,  f2  (r  &t))}. 

For  any  S  €  TermJ(T),  let  S'  G  Term^ir  list)  be  a  frame  stack  that  diverges 
when  applied  to  any  term  of  type  r  list,  say 

S'  Id  o  (case  —  of  nil  list)  \  h::t=>it{T  list)). 

Now  neither  S'  t  (fir)  nor  S'  t  {Q  (rlist))  hold,  because  of  the  divergence 
properties  of  fl.  Therefore  by  definition  of  r,  we  have  (S,  S')  G  r^.  Combining 
this  with  (13)  yields  S  t  (Gr)  ^  S'  r  (G rlist).  But  S'  was  chosen  so  that 
S'  T  L  does  not  hold  for  any  L  G  Term(r  list).  Therefore  S  t  (Gr)  does  not 
hold  either,  as  required.  G 

5.3  A  graph  lemma 

In  order  to  prove  Examples  3.4  and  3.5  we  use  the  following  source  of  TT-closed 
term-relations. 
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Lemma  5.2  (Graphs  of  frame  stacks  are  xT-closed) 

For  each  S  6  Stack{T,T')  the  term-relation  graphs  ^  ■Re/(r,r')  defined  by 

graphs  =  {(M,  M')  \  S@M  =obs  M' :  r'}. 

is  TT-closed.  (The  definition  of  the  application  operation  was  given  just 

after  Definition  4..5.) 

Proof.  We  have  to  show  that  {graphsY'^  ^  graphs-  Note  that  by  Theo¬ 
rem  4.15 

(14)  graphs  =  {{M,M')  \  {S@M,M')  £  A-r’}- 

li  S'  o  S  denotes  the  result  of  appending  the  frames  in  5  to  a  frame  stack 
S',  then  an  induction  on  the  length  of  S  yields 

(15)  {S'oS)tM  ^  S't  {S@M). 

Prom  (14)  and  (15)  we  get 

{S' ,  S")  {Ar>)'^  {S'  oS,S")  e  {graph s^ 

and  hence  that 

{N,N')  e  {graphsf^  {S@N,N')  e  {A^'f'^ . 

But  by  Lemma  4.11(i),  (A,-')^^  =  ^r'-  Therefore  if  {N,N')  G  {graph sY^^ , 
then  {S@N,  N')  G  A,-'  and  hence  {N,  N')  G  graphs,  required.  □ 

5-4  Proof  of  Example  3-4 

Suppose  G  is  a  closed  term  of  type  unit  y  a  {a  a).  In  view  of  the 
properties  of  =obs  given  in  Fig.  8,  to  establish  the  claim  in  this  example  it 
suffices  to  show  for  all  r  G  Typ  and  M  G  Term{T)  that  either 

(16)  GtM  =obs  :  T 
or 

(17)  GtM  =obs  M:t. 

Given  r  G  Typ  and  M  G  Term{T),  let  S  G  Stack{unitlist,T)  be  the  frame 
stack 

S  ^  Ido  (case  —  of nil=^ M  |  h::t=^ M) 

and  consider  graphs  ^  Rol{unit  list,T)  as  in  Lemma  5.2.  By  Theorem  4.13(ii) 
we  have  {G,  G)  G  A^nu  =  Vr  {r'^'^  r'^’’').  So  since  by  Lemma  5.2  graphs  is 

TT-closed,  we  have 

(18)  {G  unit  list,GT)  G  graphs  — >•  graphs- 

By  property  (iii)  in  Fig.  8,  we  have  (nil„n,(,  M)  G  graphs-  Therefore  from  (18) 
we  get  that  {G  unit  list  iiWunitiG t  M)  G  graphs,  i-®- 

(19)  case  {G  unit  list  nil„nit)  of  nil  =^M  |  h::t=^M  =obs  Gt  M  :t- 
Now  either  G  unit  list  nil„„,t  1)  C  for  some  C,  or  not.  In  the  first  case  we  get 

case  {G  unit  list  nil„„i()  of  nil  =>  M  \  hv.t^M  =ciu  M  :  r 
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and  in  the  second  we  get 

case  {G  unit  list  of  nil  M  |  h::t^M  =ciu  :  t. 

Then  by  Theorem  5.1  and  (19),  the  first  possibility  yields  (17),  whereas  the 
second  yields  (16). 

5. 5  Proof  of  Example  3. 5 

Let  L(a),  I  and  J  be  as  defined  in  Example  3.5.  By  the  results  in  Sec.  5.1,  to 
prove 

a,  £:  a  list  J  a  {I  a  £)  =obs  ^  list 
a,  g  :  L{a)  \- 1  a  {Jag)  =obs  9  •  L{a) 

it  suffices  to  show  for  all  r  €  Typ,  L  6  Term{T  list),  and  G  €  Term{L{T)) 


that 

(20) 

J  T  {I  T  Ij)  — obs  L  ,  T  list 

and 

It{JtG)  =obs  G  :  L{t). 

For  the  latter,  in  view  of  the  definition  of  L{t)  it  suffices  to  show  for  all 
t'  €  Typ,  M'  G  Term{T'),  and  F  G  Term{T  -¥t'  -¥  r')  that 

(21)  It{JtG)t'M'F  =obs  Gt'M'F-.t'. 

We  tackle  (20)  first.  Applying  the  beta-conversion  properties  in  Fig.  8  to 
the  definitions  of  I  and  J  yields 

{22)  It  Lr'  M'  F  =obs  caseLofnW^  M'  \  h:\t=>  F  h{lTtT'  M'  F) :  rlist 
(for  all  L,  M',  and  F  of  appropriate  type)  and  then 

(23)  Jt{ItL)  =obs  caseLofnil=^mlr\h::t=^h::{JT{lTt)):Tlist. 

From  (23)  it  follows  that  r  *=  {(Af,  M')  |  M  =obs  J t  {It  M')  :  r  list}  satisfies 
the  bisimulation  conditions  in  property  (vii)  of  Fig.  8  and  hence  is  contained 
in  =obs-  Since  {Jt{ItL),L)  G  r,  we  have  (20). 

Turning  to  the  proof  of  (21),  consider  the  frame  stack  S  G  Stack{T  list,T') 
defined  by 

S  ^  Ido  (case  —  of  nil  M'  |  h ::  t  =>  {F  h){lTt  t'  M'  F)). 

In  view  of  (22),  we  have  S@L  =obs  ItLt'  M'  F  :t  list  and  therefore 

rM',F  =  {{L,  M")  IItLPM'F  =obs  M"  :  r  list} 

is  a  TT-closed  member  of  Rel{T  list,T')  by  Lemma  5.2.  So  for  each  G  G 
Term{L{T)),  since 

{G,  G)  G  Ai(^)  =  Vr  {r'^^  ^  (A^  ->  r^"^)  r'^'^) 

we  have  that 

{G  T  list,G  t')  G  rM',F  (At  rM',F  ->■  »”m',f)  ->■  rM',F- 
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Vanilla  PCF 

(call-by-name  evaluation;  termination  at  function  types  is  not  observable) 


where  in  general 

ri  r2  ='  {iF,F')  \  \/{A,A')  e  n  iiFA,F'A')  G  r2)}. 


‘Lazy’  PCF 

(call-by-name  evaluation;  termination  at  function  types  is  observable) 

A,,^^(r)  11'  (AA,.(r)(A,,(r-)))^^ 

where  in  general 

An  (r2)  ='  {(Ax  :  n  (M),Ax  :  n  (M'))  | 


'^{A,A')  €  n  {{M[A/x],M'[A'/x])  G  rj)}. 


Call-by-value  PCF 

(call-by-value  evaluation;  hence  termination  at  function  types  is  necessarily  observable) 

A..^.,(f)  H'  (A„A,,(f)(A,,(f)))‘^'^ 

where  in  general 

A„ n  (r2)  =  {(Ax  :  n  (M),  Ax  :  n  (M'))  | 


'i{C,C')  G  n  with  C,C'  canonical  ((M[C'/x],M'[C"/a^])  €  i'2)}. 


Fig.  9.  Some  actions  of  on  term-relations 

Prom  (22)  and  the  definition  of  rM>,F  we  get  that  N  1=  AQ!(nila)  and  C  == 
Aa{Xh  :  a{Xt :  a  list  {h  ::  t)))  satisfy 

(iV  T,  M')  G  rM',F  and  (C  r,  F)  G  Ar  — >  rM',F  tm',f 

and  hence 

(G  r  list  {N  t)  (G  r) ,  G  r'  M'  F)  G  rM'.F- 

Therefore  I  t{G  t  list  {N  r)  (G  r))  t'  M'  F  =obs  Gr*  M'  F  :r',  from  which  (21) 
follows  by  definition  of  J. 


6  Conclusion 

Notions  of  contextual  equivalence  of  programs  have  a  final,  as  opposed  to  ini¬ 
tial,  character — in  that  program  phrases  are  identified  as  much  as  possible 
within  some  observational  framework.  Therefore  it  is  reasonable  to  expect  V- 
types  to  have  strong  parametricity  properties  with  respect  to  such  a  notion  of 
equivalence.  The  unpublished  work  of  Mitchell  and  Moggi  on  the  maximally 
consistent  model  of  PLC  vindicates  this  expectation,  and  the  work  presented 
here  provides  further  evidence,  this  time  in  a  context  more  directly  relevant 
to  functional  programming.  It  seems  that  in  the  presence  of  fixpoints,  poly- 
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morphic  types  have  very  rich  properties  up  to  contextual  equivalence  and  that 
operationally-based  logical  relations  provide  a  convenient  way  of  proving  these 
properties.  The  applications  in  the  previous  section  are  certainly  just  a  small 
selection  of  the  results  which  can  be  proved  using  the  machinery  of  Sec.  4. 
The  Galois  connection  (-)^  between  term-relations  and  stack-relations  (Def¬ 
inition  4.7)  seems  the  most  interesting  ingredient  of  that  machinery.  One  of 
its  roles  is  to  tie  the  operational  semantics  into  the  logical  relation.  This  idea 
is  reinforced  in  Fig.  9,  where  we  mention  some  alternative  actions  of  — >■  on 
term-relations  (cf.  Definition  4.2)  which  fit  contextual  equivalence  for  ‘lazy’ 
and  call-by-value  PCF.  (Of  course  in  each  case,  the  definition  of  —  t  —  and 
hence  of  (— )^^,  changes  to  match  the  changed  operational  semantics  and/or 
observational  scenario;  and  in  the  second  case  the  notion  of  frame  stack  is 
different  as  well.) 

As  mentioned  in  Sec.  4,  another  role  of  the  (-)’’’  operation  is  to  provide  a 
syntactic  version  of  the  domain-theoretic  notion  of  admissibility.  The  recent 
upsurge  in  operational  techniques  in  the  semantics  of  higher  order  program¬ 
ming  languages  has  been  fuelled  to  a  certain  extent  by  developing  syntactical 
versions  of  domain-theoretic  methods  (see  [21,4]  for  example).  Here  it  may  be 
interesting  to  go  in  the  opposite  direction.  The  Galois  connection  (-)'’’  arose 
from  purely  operational  considerations  (in  fact,  as  a  way  of  dealing  with  dy¬ 
namic  allocation  of  local  state  in  the  logical  relation  introduced  in  [26]);  but  it 
may  be  useful  to  use  a  denotational  version  of  (~)^  for  ‘extensional  collapses’ 
when  constructing  models  of  polymorphism  and  recursion.  Denotationally, 
strict  continuous  functions  play  the  role  of  frame  stacks  (evaluation  contexts). 
So  given  domains  D  and  D',  we  may  consider  the  evident  Galois  connection 
between  relations  R  G  DxD'  and  relations  S  C  (D  — o  /)  x  {D'  —o  /)  induced 
by 

/  T  d  ^  f{d)  =  T 

where  I  =  { J.,  T}  is  the  two-element  domain  with  ±  E  T  and  D  —o  I  denotes 
the  usual  domain  of  strict  continuous  functions  from  D  to  I.  It  would  be 
interesting,  and  possibly  useful,  to  have  a  more  explicit  characterisation  of 
what  are  the  TT-closed  relations  in  this  sense.  ^ 

The  particular  type  system  of  PCF'''  was  chosen  merely  to  be  able  to 
state  and  prove  Example  3.5.  I  believe  that  the  techniques  presented  in  this 
paper  will  extend  quite  smoothly  to  show  operational  isomorphisms  between 
appropriate  pure  PLC  types  and  other  type-theoretic  notions  important  to 
programming  language  theory,  such  as  recursive  types.  One  direction  which 
will  be  pursued  in  future  work  is  the  combination  of  V-types  with  intuition- 
istic  linear  types  (!  and  — o  types).  Plotkin  [29]  has  pointed  out  that  in  the 
presence  of  fixpoints,  and  with  relational  parametricity,  this  system  provides  a 


One  thing  is  clear:  such  a  TT-closed  relation  on  D  x  D'  is  in  general  something  more 
than  just  a  chain-closed  and  bottom-containing  relation;  thanks  to  Glynn  Winskel  (private 
communication)  for  pointing  this  out. 
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very  expressive  denotational  metalanguage.  Equipping  the  type  system  with 
a  suitable  operational  semantics  and  associated  notion  of  observational  con¬ 
gruence,  techniques  similar  to  the  ones  introduced  here  should  provide  a  term- 
model  construction  for  the  formal  version  of  parametricity  that  Plotkin  had 
in  mind  for  this  system.  Another  interesting  direction  (from  the  point  of 
view  of  the  foundations  of  object-oriented  programming)  would  be  to  define 
operationally-based  logical  relations  for  combinations  of  subtyping,  existential 
polymorphism,  and  recursion  (cf.  [31]). 
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Abstract 

In  a  previous  paper  we  have  defined  a  semantic  preorder  called  operational  subsump¬ 
tion,  which  compares  terms  according  to  their  error  generation  behaviour.  Here  we 
apply  this  abstract  framework  to  a  concrete  language,  namely  the  Abadi-Cardelli 
object  calculus.  Unlike  most  semantic  studies  of  objects,  which  deal  with  typed 
equalities  and  therefore  require  explicitly  typed  languages,  we  start  here  from  a  un¬ 
typed  world.  Type  inference  is  introduced  in  a  second  step,  together  with  an  ideal 
model  of  types  and  subtyping.  We  show  how  this  approach  fiexibly  accommodates 
for  several  variants,  and  finally  propose  a  novel  semantic  interpretation  of  structural 
subtyping  as  embedding-projection  pairs. 


1  Introduction 

In  a  previous  paper  [10]  we  have  defined  a  semantic  preorder  called  opera¬ 
tional  subsumption,  which  compares  terms  according  to  their  error  genera¬ 
tion  behaviour.  Together  with  the  technical  device  of  labeled  reductions,  used 
as  a  syntactic  characterization  of  finite  approximations,  this  semantics  was 
shown  to  adequately  interpret  recursive  types  and  subtyping.  In  this  paper 
we  apply  this  approach  to  FOb,  the  lambda-calculus  of  objects  of  Abadi  and 
Cardelli  [2].  Because  we  work  with  a  concrete  language  instead  of  an  abstract 
framework,  several  steps  can  be  simplified,  so  the  resulting  semantic  struc¬ 
ture  is  intuitively  quite  obvious.  Moreover,  a  “context  lemma”  in  the  untyped 
language  gives  us  a  simple  induction  principle  for  proving  many  properties 
of  types.  The  goal  is  to  show  that  the  “Coverage  of  Operational  Semantics” 
[21]  can  be  widened  to  also  deal  with  subtyping  systems.  More  concretely,  we 
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show  several  directions  where  this  approach  can  simplify  or  deepen  previous 
results. 

First,  we  give  an  interpretation  of  second-order  bounded  quantification  for 
universal  and  existential  types.  This  extends  previous  work  on  ideal  mod¬ 
els  [18]  with  subtyping.  Furthermore  it  answers  to  Abadi  et  al  [3],  who  won¬ 
dered  whether  their  approach  would  apply  to  a  suitable  notion  of  operational 
ideals:  this  is  exactly  what  is  done  here. 

Then  we  have  a  direct  way  of  interpreting  typed  equivalences  of  object- 
calculi  (equivalences  which  depend  on  the  type  context  in  which  objects  are 
considered).  Gordon  and  Rees  [11]  used  the  coinduction  principle  of  Howe  [14] 
to  interpret  these  equivalences;  however  this  required  a  heavy  apparatus  which 
switches  between  typed  and  untyped  worlds:  in  addition  to  the  reduction 
relation  they  had  to  define  a  labeled  transition  system  and  a  “compatible 
refinement”  relation.  By  contrast  our  interpretation  is  based  on  the  untyped 
reduction  relation.  Moreover  we  can  validate  second-order  typed  equivalences, 
which  remained  an  open  issue  in  [11]. 

Finally  we  give  a  semantic  interpretation  of  structural  subtyping,  which  is 
useful  for  solving  the  problem  known  as  “polymorphic  object  update” .  Bruce 
and  Longo  [7]  have  demonstrated  that  in  usual  interpretations  of  subtypes  as 
subsets  the  polymorphic  type  VX  <  T.X  X  can  only  contain  the  identity 
function,  which  makes  it  impossible  to  type  some  elementary  updating  op¬ 
erations  on  objects.  The  problem  is  developed  in  more  detail  in  Chapter  16 
of  [2].  Some  authors  [13,20]  have  proposed  to  solve  the  problem  by  restrict¬ 
ing  the  subtype  relation  in  various  ways  so  as  to  ensure  that  the  subtypes 
have  the  same  structure  as  the  supertype.  Here  we  show  that  usual  subtyping 
and  structural  subtyping  are  two  distinct  notions  semantically.  The  former 
corresponds  to  a  subset  relation,  while  the  second  corresponds  to  embedding- 
projection  pairs  in  the  subsumption  ordering.  Both  subtyping  notions  can 
cohabit  and  could  be  included  in  the  type  syntax  if  so  desired. 

2  The  untyped  object  calculus 

The  syntax  shown  in  Figure  1  is  built  from  the  set  uj  of  natural  numbers,  from 
a  countable  set  Af  of  names  (for  object  fields)  and  a  set  X  of  variables,  e  is  a 
constant  for  errors.  The  main  difference  from  [2]  is  that  terms  are  labeled,  i.e. 
decorated  at  each  subterm  with  a  natural  number  or  oo.  Here  the  purpose  of 
labels  is  merely  to  introduce  a  notion  of  finite  projection  for  interpreting  re¬ 
cursive  types.  In  [10]  we  also  used  labels  for  an  abstract  definition  of  erroneous 
terms;  this  is  not  needed  here,  since  we  work  in  a  concrete  calculus  for  which 
the  erroneous  terms  are  just  those  which  reduce  to  the  error  constant.  Intu¬ 
itively,  each  label  acts  as  a  counter  limiting  the  number  of  interaction  steps 
between  the  corresponding  subterm  and  its  context.  When  a  label  reaches 
0,  it  becomes  a  divergent  term,  with  which  no  interaction  is  possible.  The 
infinite  label  oo  imposes  no  limit,  so  for  better  readability  it  will  usually  be 
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(indexes)  i,j,kE.u> 

(labels)  n,  m  G  a;  U  {00} 

(names)  I,  I'  €  JV 
(variables)  x,y,z  £  X 

(terms)  a,b  eT  ::=  a;”  |  e”  |  a”  |  (Ax.a)”  |  (a  6)”  | 

Ui  =  I  (a./)"  |  (a^l  =  <;x.b)^ 


(hnf)  hen  ::=  x^+^  \  {h  \  \  {h^l  =  <;x.b)^+^ 

(values)  veV  ::=  h\  {Xx.a)^+^  1  ( [Zi  =  )"+i  |  e"+i 


Fig.  1.  Syntax 

omitted.  In  consequence  there  is  an  obvious  embedding  of  usual,  unlabeled 
terms  into  labeled  terms  by  decorating  each  subterm  with  00.  Furthermore 
00  is  considered  the  successor  of  itself,  so  by  abuse  of  notation  a  superscript 
n  +  1  may  denote  00,  in  which  case  n  also  equals  00. 

Like  in  the  lazy  A-calculus,  every  function  or  object  is  a  value  if  its  label 
is  >  0;  furthermore  open  terms  in  head  normal  form  (i.e.  starting  with  a 
free  variable)  are  also  values.  Finally,  notice  that  e  is  a  value,  which  is  a  bit 
uncommon,  but  is  an  essential  point  of  the  approach. 

We  adopt  common  conventions  for  simplifying  notation:  Xxy.a  for  Xx.Xy.a, 
(abc)  for  {{ab)c).  In  an  object  Lk  =  it  is  implicitly  understood  that 

the  order  of  methods  is  irrelevant,  and  that  for  i,  j  e  I,  Ij  whenever  j. 
A  similar  convention  will  be  used  for  types  in  Section  4.  A  method  /  =  a  in  an 
object  is  an  abbreviation  for  I  =  qx.a,  where  x  does  not  occur  free  in  a;  in  that 
case  it  is  called  a  field.  Some  common  terms  are  I  =  Xx.x,  K  =  Xxy.y,  Q  = 
{Xx.xx){Xx.xx).  A  context  C{—]  is  a  term  possibly  containing  occurrences  of 
a  “hole”;  C[a]  is  the  term  obtained  by  filling  the  holes  with  a,  with  possible 
variable  capture.  A  substitution  cr  is  a  finite  map  from  variables  to  terms;  aa 
is  the  term  obtained  by  substituting  free  occurrences  of  a;  in  a  by  <7(0:),  while 
avoiding  variable  capture;  a  single  substitution  is  written  a[x  :=  6].  The  sets 
and  are  respectively  the  closed  terms  and  the  closed  values.  A  closing 
substitution  for  a  is  a  a  such  that  aa  6  The  set  T”  is  the  set  of  terms 
with  outermost  label  less  or  equal  to  n. 

The  one-step  reduction  relation  is  the  least  relation  satisfying  the  rules 
in  Figure  2.  Labels  and  errors  are  the  two  unusual  factors  in  these  rules. 
Labels  are  decremented  at  each  step  where  a  term  is  “deconstructed” ;  in  case 
n  4- 1  =  n  =  00,  i.e.  when  the  counter  is  infinite,  the  rules  just  become  the 
usual  rules  for  reduction  of  functions  and  objects.  Errors  are  a  way  to  avoid 
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m 

{a[x  :=  6])” 

(Act) 

(Aa:.a)”+^/  ^  e” 

(Av) 

(Aa;.a)"'^^4=/  =  ^x.b  e” 

(oct) 

Ui  =  -> 

f  {aj[x  :=  Ui  =  iij  el 

I  e"  otherwise 

(ov)  [ 

li  =  =  <;x.b  — >•  Ui  =  <;x.ai'^^'^^^\lj  =  <;x.bl'^ 

(op) 

[/i  = 

m 

a)  £” 

(ea) 

e^+Kl  £" 

{ev) 

g-n+l^^  _  ^ 

(Ae) 

(Ax  gl+min(m,n) 

(^") 

aP 

(^) 

(cong) 

a  b  VC[— ],C'[a]  (^[6] 

Fig.  2.  Reduction  rules 


so-called  “stuck  terms”  in  the  literature:  instead  of  having  terms  which  do 
not  reduce  but  are  not  values,  we  explicitly  reduce  them  to  the  error  constant. 
Once  generated,  errors  are  always  propagated  further  in  the  computation,  i.e. 
there  is  no  exception  handling  construct;  however,  since  this  is  a  call-by-name 
calculus,  a  context  may  discard  an  error  in  the  same  way  that  it  would  discard 
a  divergent  subterm:  for  example  Ke  reduces  to  I. 

The  (Ae)  rule  is  an  ad  hoc  rule  which  allows  us  to  greatly  simplify  the 
abstract  framework  of  [10]:  instead  of  observing  “ability  to  interact”  we  will 
just  observe  reduction  to  e.  Intuitively  the  rule  is  motivated  by  the  fact  that 
a  function  containing  e  can  do  nothing  “useful”  and  therefore  is  equivalent  to 
e.  By  contrast,  there  is  no  such  rule  for  objects,  because  a  method  containing 
e  can  always  be  overridden. 

In  this  untyped  calculus  the  ^  operator  can  not  only  override  existing 
methods,  but  also  add  new  methods,  which  is  more  liberal  than  in  [2].  This  is 
a  deliberate  choice,  so  that  the  same  calculus  can  be  used  to  interpret  various 
type  systems.  In  the  next  section  we  start  with  the  type  system  of  [2],  in 
which  only  override  can  be  well-typed;  later  we  extend  it  with  the  system  of 
[17]  which  also  supports  method  extension. 
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The  A:-transitive  closure  of  is  written  ->■,  its  reflexive,  transitive  closure 
is  written  A,  and  the  symmetric  closure  of  A  is  written  =. 

Theorem  2.1  (Confluence)  The  language  is  confluent:  whenever  a  b 
and  a  c  there  is  a  d  such  that  b  d  and  c-^  d. 

Proof.  Standard  Tait  technique  using  parallel  reductions;  see  for  example 
[22,9].  □ 

Definition  2.2  [Convergence] 

A  term  a  converges  (a  J^)  iff  €  V,  a  A  v.  Otherwise  a  diverges  {a  -fj-). 

3  Operational  Subsumption 

The  idea  of  operational  subsumption  is  a  simulation  relation  based  on  obser¬ 
vation  of  errors.  In  the  abstract  framework  of  [10]  we  had  to  build  a  complex 
machinery  in  order  to  define  the  notion  of  “erroneous  terms” .  Here  this  can  be 
much  simpler;  like  in  [9],  we  have  a  rule  (Ae)  which  removes  a  A-abstraction 
if  its  body  is  an  error;  this  rule  is  admissible  because  it  does  not  break  con¬ 
fluence  (Theorem  2.1  above).  As  a  result  it  suffices  to  observe  reductions  to  e 
as  a  basis  for  subsumption. 

Definition  3.1  [Error  terms] 

af  3n,  a  A 

S  will  denote  the  set  {a  ]  af}  of  error  terms. 

Definition  3.2  [Contextual  subsumption] 

A  term  a  contextually  subsumes  another  term  6,  written  a  b,  iff  it 
generates  fewer  errors  in  all  program  contexts: 

^  VC[-],C'[o]t  C[6]t 

Subsumption  is  a  lattice  with  bottom  and  top  e.  The  symmetric  closure 
of  E  is  written  =. 

Lemma  3.3  Subsumption  contains  reduction 

a  — y  b  — r'  a  —  b 

Proof.  Direct  from  definition,  knowing  that  the  language  is  confluent.  □ 

For  convenience  of  proofs  it  is  useful  to  establish  a  “context  lemma”  which 
allows  us  to  only  inspect  a  restricted  set  of  contexts. 

Definition  3.4  An  applicative  context  jR[— ]  is  a  closed  context  generated  by 
the  following  syntax: 

J![-l  [-)”  I  {RI-]  a)"  |  (BH.i)"  I  (iSH*-/  = 

Definition  3.5  Applicative  subsumption  is  the  relation  defined  as 

^  V£r,Vil[-],i2[aa]t  R[ba]i 


5 


Dami 


Lemma  3.6  (i)  \x.a  h  =>  6  f  V(6  A  \x.h'  A  a  h') 

(ii)  a  =  [Zi  =  b  6 1  V(6  4  [/,  =  ,  J  C  /  A  Vj  € 

J,  aj[rr  :=  a]  E“pp'  bj[x  :=  6]) 

Proof. 

(i)  Since  {Xx.a).lj  and  {{Xx.a)^l  =  ca;.c)t,  b  cannot  reduce  to  an  object.  So 
either  ftf,  or  6  4  Xx.b'.  Then  R[a[x  :=  c]]  5“^^'  R[b'[x  :=  c]]  for  every 
R[—],c,  which  implies  a  b'. 

(ii)  Similar  reasoning. 

□ 


Theorem  3.7  (“Ciu”,  context  lemma) 

a  b  a  b 

Proof.  The  ^  direction  is  trivial,  since  applicative  contexts  are  contexts. 
The  difficult  part  is  the  <=  direction.  We  proceed  by  induction  on  the  length 
of  the  proof  of  Cfajt,  i.e.  we  will  show 

Vi,VC'[-],  iiC[a]  4  e"+i)  A  (a  b))  ==^  C[b]i 

The  case  i  =  0  is  trivial  because  then  C[—\  is  the  empty  context  and  both  a 
and  b  are  errors.  If  i  >  0  and  the  first  reduction  step  occurs  either  in  C{—\ 
or  in  a,  i.e.  if  Cfa]  — )•  C'\a'\  with  either  C[—\  — >  ]  or  a  — >■  a',  then  we 

can  directly  use  the  induction  hypothesis.  Finally  we  can  also  ignore  the  cases 
where  ftf,  which  again  are  trivial.  So  we  are  left  with  the  following  cases: 

•  cases  (u),  (i/“):  easy,  a  similar  step  can  be  performed  with  C[b]  and  then  we 
can  appeal  to  the  induction  hypothesis. 

•  cases  (e/3),  (ecr),  (sv):  easy  again  because  both  a  and  b  must  be  error  terms. 

•  cases  (Act),  (Xv),  {off):  these  are  the  cases  which  generate  an  error.  By  the 
preceding  Lemma  a  similar  step  can  be  performed  with  C[b]  and  then  the 
result  follows  from  induction  hypothesis. 

•  case  (XP):  here  a  must  be  of  shape  Xx.a'  and  C\—\  must  contain  a  subterm 

of  shape  ((— )P[— ])•  Let  D[—],E[—]  be  the  contexts  repectively  obtained 
by  replacing  this  subterm  by  (a.B[— ])  or  {bB[—]).  Clearly  C[a]  =  D[o\ 
and  D[a\  ->  i)'[a]  where  the  same  subterm  is  replaced  by  a'\x  :=  B[a]]. 
We  know  D'[a]1;,  and  therefore  by  induction  hypothesis  D'[b]1i.  Now  by 
the  preceding  Lemma,  b  4  Xx.b*  with  a'  b'.  Again  by  induction 

hypothesis,  E'[b]^,  where  E*[b]  is  obtained  from  D'[b]  by  replacing  the  same 
subterm  by  b'[x  :=  B[6]].  Finally,  since  E[b]  — >•  E'[b]  and  E[b]  =  C'[6],  we 
have  proved  C[6]t. 

•  cases  (oa),  (ov):  like  the  preceding  case,  using  the  second  clause  of  Lemma  3.6. 

□ 

Because  of  this  Theorem  we  will  henceforth  omit  the  or  superscripts. 
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Example  3.8  Thanks  to  the  preceding  Theorem  we  can  easily  prove  the  fol¬ 
lowing  laws  through  induction  on  applicative  contexts: 

(i)  Xxi . . .  Xi-eai  ...aj  =  s 

(ii)  a  E  Xx.a  x  if  a;  is  not  free  in  a 

(iii)  Ui  =  g  Uj  =  if  J  C  / 

(iv)  -'( [Z  =  a,l'  =  (;x.  x.l"]  g  [Z'  =  a] ) 

(v)  [Z  =  qx. [Z  =  qy.x']']  =  [Z  =  qx.x'] 

(vi)  Ui  =  qx.ai^^ , Z  =  e]  =  [Zi  =  qx.ai^^"] 

(vii)  U^e 

The  first  law  is  quite  obvious.  The  second  law  is  the  familiar  77-rule  of  the  A- 
calculus;  here  it  is  not  an  equality  because  77-reduction  is  always  sound,  while 
77-expansion  is  obviously  not  sound  when  a  is  an  object.  The  third  law  is  the 
basis  for  object  subtyping:  an  object  with  more  methods  subsumes  an  object 
with  fewer  methods.  The  fourth  law  shows  that  objects  are  compared  not  only 
on  the  basis  of  field  access,  but  also  on  field  update:  accessing  field  I'  would 
yield  the  same  result  on  both  sides,  but  updating  field  Z  would  make  the  two 
object  incomparable.  The  fifth  law  is  an  example  that  is  not  covered  by  the 
equational  system  of  [2],  because  it  cannot  be  shown  by  a  finite  proof;  this  is 
similar  to  the  problem  of  equivalence  or  subtyping  of  recursive  types  [4].  The 
last  two  laws  are  consequences  of  our  design  choice  to  also  support  method 
addition  in  the  untyped  calculus;  if,  instead,  we  had  only  method  override, 
then  the  situations  would  be  reversed  (law  6  would  be  an  inequality  and  law 
7  would  be  an  equality). 

4  Inference  of  Abadi-Cardelli  types 

This  section  introduces  a  hybrid  type  system,  inspired  from  both  [2]  and  [18], 
which  includes  object  types,  bounded  universal  and  existential  quantification, 
and  recursive  types.  Like  in  [18],  this  is  an  impredicative,  implicitly  typed  sys¬ 
tem,  so  there  are  neither  type  abstraction  constructs  for  universal  types  nor 
pack/open  constructs  for  existential  types;  such  types  are  introduced  and 
eliminated  in  the  inference  rules  without  help  from  the  term  syntax.  Similary, 
the  isomorphisms  between  recursive  types  and  their  unfoldings  are  handled  au¬ 
tomatically  in  the  subtyping  rules,  so  there  is  no  need  for  explicit  fold/unfold 
constructs  in  the  term  syntax.  Apart  from  these  surface  difiPerences,  the  ty- 
pable  objects  are  the  same  as  in  [2],  so  for  example  this  system  can  type 
method  override,  but  not  method  addition  (a  more  powerful  system  will  be 
discussed  in  the  next  section) .  On  the  other  hand  the  only  significant  difference 
with  respect  to  [18]  is  the  addition  of  subtyping  and  bounded  quantification. 
The  intersection  and  union  types  of  [18]  are  not  handled  here,  not  because 
of  any  technical  difficulty,  but  just  because  they  are  of  limited  interest  in  the 
current  context. 
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Type  syntax 

T,C7  ::=  TOP  \X\T^U\Ui: 

I  V(X  <:  T)U  I  3{X  <:  T)U  \  nX.T 

A  basis  P  is  a  list  of  statements  of  the  form  x  :  T  (type  assumption)  or 
X  <:  T  (subtype  assumption).  A  basis  is  well-formed  iff  the  subjects  of  all 
assumptions  are  distinct,  and  the  subject  A  of  a  subtype  assumption  X  <:T 
does  not  appear  free  in  T  nor  in  any  previous  assumption.  Judgements  are  of 
the  form  T\-T  <:U  (subtyping  judgement)  or  P  h  a  :  T  (typing  judgement). 
The  subtyping  rules  are  given  in  Figure  3.  These  are  the  same  as  [2],  except  for 
the  fold/unfold  rules  which  express  the  isomorphism  between  recursive  types. 
Observe  that  object  types  support  width  subtyping,  but  no  depth  subtyping 
(the  types  of  the  methods  are  invariant). 

Type  inference  rules  are  defined  in  Figure  4.  Most  rules  are  standard. 
The  rules  for  introduction  and  elimination  of  quantified  types  are  taken  from 
[18],  with  some  adaptations  for  accommodating  bounds  on  the  quantified  type 
variable. 

The  type  interpretation  is  very  similar  to  what  we  did  in  [10],  except  that 
here  we  have  second-order  types  and  object  types  instead  of  record  types. 
Types  are  interpreted  as  ideals  in  (T‘',  1),  i.e.  non-empty,  downward-closed 
subsets  of  closed  terms.  Let  Tset  denote  the  set  of  such  subsets.  Letters 
t,  u,  V  range  over  Tset.  For  any  t  G  Tset,  t"  denotes  the  set  {o”|a  €  t}  (finite 
projection).  Tset  is  a  lattice  ordered  by  subset  inclusion,  with  top  element 
T  =  and  bottom  element  i.  =  {a  G  T*"  |  a  -fl-}.  Notice  that  so  far  neither  T 
nor  J_  has  a  corresponding  expression  in  the  type  syntax.  A  type  environment 
77  is  a  mapping  from  type  variables  to  Tset.  Given  a  type  environment,  a  type 
interpretation  function  Ti[-]  maps  types  to  members  of  Tset.  Figure  5  gives 
the  type  interpretation.  Like  in  [10],  we  interpret  recursive  types  through  in¬ 
dexed  families  of  type  interpretations,  following  an  idea  of  [8];  non-contractive 
type  expressions,  like  for  example  pX.X,  are  naturally  mapped  to  the  bottom 
type  2. 

Lemma  4.1  (i)  VT,  77,  Ti[T],,  G  Tset. 

(ii)  A  type  is  trivial  if  its  interpretation  contains  e^.  If  rj  does  not  map  any 
type  variable  to  a  trivial  type,  then  Ti[r],,  is  non-trivial  for  any  T . 

Proof.  Induction  on  T. 

Definition  4.2  A  type  environment  77  satisfies  a  basis  F,  written  77  |=  F,  iff 
Ti[A']„  C  Ti[r],,  whenever  (A  <:  T)  G  F.  Similarly,  a  closing  substitution 
on  terms  a  satisfies  a  basis  F  and  a  type  environment  77,  written  a  [=  (F,77), 
iff  xcr  G  Ti[T],,  whenever  {x  :  T)  e  F.  The  notation  77,  cr  |=  F  abbreviates 
77  |=F  Ao- 1=  (F,77) 


^  for  an  explanation  of  contractive,  see  the  literature  on  recursive  types,  e.g.  [8,4,18,2] 
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(top) - 

r  h  T  <:  TOP 


(refl) - 

PhX  <:X 


(env) - 

T,X  <:T\-X  <:T 

r  h  T2  <:  Ti  r  h  C/i  <:  U2 

(arrow) - 

r  h  Ti  — U\  <:  T2  — ^  U2 


(obj ) - — - 

r  h  Di :  Ij  :  <:  Ui  : 

r  h  Ta  <:  Ti  T,X  <:  T2  h  Ui  <:  U2 

(for  all) - 

r  h  V(X  <:  Ti)C/i  <:  'i(X  <:  T2)U2 

ri-ri<:T2  r,X<:riht/i  <:t/2 

(exists) - - - = - ^ - 

r  h  3(X  <:  Ti)Ui  <:  3(X  <:  T2)U2 

T,X  <:Y\-T<-.  U 

(rec) - 

r  h  pX.T  <:  pY.U 


(un  fold) - 

r  h  ixX.T  <:  T[X  :=  pX.T] 


(fold) - 

r  h  T[X  :=  pX.T]  <:  pX.T 


Fig.  3.  Subtyping  rules 


Theorem  4.3  (Type  soundness) 

(i)  r  h  T  <:  f/  Vr;  1=  r,  Ti[r],  C  Ti[C/],. 

(ii)  r  h  o  :  T  =J>  Vt/,  <T  1=  r,  a(7  G  Ti[r],. 

(iii)  r  h  a  :  r  ^(4). 

Proof.  1)  induction  on  the  judgement  T  h  T  <:  Z7;  2)  induction  on  the 
judgement  P  h  o  :  T;  3)  direct  from  2)  and  from  the  preceding  Lemma.  □ 


9 


This  section  explores  some  variants  of  the  type  system  to  augment  its  expres¬ 
sive  power.  Thanks  to  the  underlying  untyped  languages  and  to  Theorem  3.7 
the  soundness  of  the  new  rules  can  be  checked  quite  easily. 


Dami 


Ti[T]S  =  1 

Ti[TOP];+"  =  {o  e  T"+‘h(ot)} 

Ti[X];+*  =  >/(X)"+‘ 

Ti[r  ->  £/];+>  =  {a  e  r"+'|6  €  Ti[T];  {ab)e  Ti|ui;} 
Ti|[/i  :  =  {a  €  T'+'W  g  []  A  Vi  £  I,a.l,  e  TifTi];} 

Ti(V(Jf  <:  T)[/];+‘  =  n,cTim;«  TiCT^iiU,, 

Til3(X  <:T)U]-+'  =  UcTimr- TiCTMiU.] 

Ti[^xr);+'  =  Ti[T];j»„T 


Ti[T],  =  {a|Vn  eco,a^e  Ti[T]"} 


Fig.  5.  Type  interpretation 


5.1  Super-top  type 

The  system  presented  above  is  a  “classical”  subtyping  system  in  the  sense  that 
there  is  a  maximal  type  TOP  containing  all  non-erroneous  terms.  If  we  had 
union  types,  TOP  could  be  expressed  as  the  union  of  all  function  and  object 
types: 

TOP  =  pX.{X  -^X)UD 

In  [10]  we  have  argued  in  favour  of  an  even  bigger  type  containing  all  terms, 
including  erroneous  ones.  This  can  be  easily  incorporated  into  the  system,  by 
adding  a  new  symbol  T  in  the  type  syntax  with  interpretation  Ti[T]”+^  = 
^j-c^n+i^  and  by  adding  the  typing  rule 


All  previous  results  are  preserved,  except  that  for  type  soundness  we  have  to 
exclude  the  set  Triv  of  the  trivial  types  generated  by  the  following  syntax: 

Z  G  Triv  ::=  T  I  T  Z  I  V(A  <:  T)Z  \  a(A  <:  T)Z  \  pX.Z 

Then  the  last  point  of  Theorem  4.3  has  to  be  reformulated  as: 

r  h  a  :  T  A  T  ^  Triv  ^(af) 
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The  interest  of  the  T  type  is  that  the  following  subtyping  rule  is  sound: 


(objT) - — - 

rh  <: 

Hence  a  method  with  type  T  is  equivalent  to  an  absent  method.  We  briefly 
repeat  the  example  of  [10]  to  show  that  this  subtyping  rule  allows  us  to  type 
more  programs.  Consider  a  translating  function 

T  Xx.  [  imprime  =  x.print, 

affiche  =  x.display, 
ferme  =  a;.close  ] 

which  takes  an  “english”  object  with  three  fields  as  argument,  and  returns 

def 

a  corresponding  “french”  object.  Now  consider  object  O  =  [display  = 
’’hello”]  and  program  (T  O). affiche.  This  reduces  to  ’’hello”  without 
error;  however  it  cannot  be  typed  in  the  original  system  because  the  type  of 
Tis 

VX,  y,  Z,  [print  :  X,  display  :  Y,  close  :  Z] 

[imprime  :  X,  affiche  :  Y,  ferme  :  Z} 

and  [display  :  String]  (the  type  of  O)  cannot  be  unified  with  the  left-hand 
side  of  the  arrow.  By  contrast,  the  T  extension  allows  us  to  infer 

01-0:  [print  :  T,  display  :  String,  close  :  T] 

and  therefore  the  program  (T  O). affiche  has  type  String. 


5.2  Diamond  types 

Liquori  [17]  proposed  a  type  system  for  the  object  calculus  which  supports 
method  extension.  This  is  done  through  so-called  diamond  types  of  shape 

Ui  :  Ti  o  Ij  :  {{kli  6  /}  n  {lj\j  €  J}  =  0) 

where  the  left  part  of  the  diamond  expresses  the  available  methods  as  usual, 
while  the  right  part  specifies  the  safe  possible  method  extensions.  The  main 
subtyping  rules  are  displayed  in  Figure  6. 

Liquori  establishes  soundness  of  his  system  through  a  subject  reduction 
theorem,  showing  that  types  are  preserved  during  computation.  In  our  frame¬ 
work  soundness  can  be  shown  by  proving  that  the  typing  rules  agree  with 
the  type  interpretation.  Since  we  have  method  extension  in  the  underlying 
untyped  calculus,  the  addition  and  verification  of  diamond  types  is  direct.  We 
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Fig.  6.  Diamond  subtyping 


interpret  diamond  types  as 

{aGTi[[Zi:T>^^]]^+MVii,V6, 

{{j  eJAb[x  :=  a]  e  Ti[r,]^+i)  yj^J) 
a^lj  =  qx.b  e  Ti[Ui : 

So  this  says  that  a  method  extension  is  safe  if,  whenever  the  field  is  mentioned 
in  the  right-hand  side  of  the  diamond,  the  body  of  the  added  method  has  a 
corresponding  type.  On  the  other  hand  if  the  field  is  not  mentioned  then  there 
is  no  constraint  on  that  field  and  the  extension  is  safe  in  any  case.  Once  this 
is  understood  the  soundness  of  the  subtyping  rules  for  diamond  types  is  easy 
to  establish. 

Lemma  5.1  The  subtyping  rules  of  Figure  6  are  sound. 

Proof.  Omitted 

In  addition  we  can  easily  verify  other  properties  of  diamond  types,  not 
mentioned  in  [17].  For  example  diamond  types  are  contravariant  on  the  right, 
i.e.  the  rule 

yjeJ,Uj<:Tj 

(Contro) - 

T\-Ui:TiO  Ij  :  <:  Ui  :  o  Ij  :  UjVfJj 

is  sound.  Furthermore  our  “supertop”  type  T  is  compatible  with  diamond 
types  and  again  is  equivalent  to  absent  fields,  so  the  following  rule  is  also 
sound: 


r  h  [Zi  :  TiOlj  :  =  Ik  :  Ti,l  :Tolj  :  Tj,V  :  T]}|S 


Because  of  lack  of  space  we  do  not  repeat  here  the  type  inference  rules  of 
[17];  however  it  should  be  clear  that  soundness  of  these  rules  can  be  established 
by  similar  means,  i.e.  without  need  for  a  subject-reduction  theorem. 
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6  Typed  equivalences 

In  calculi  with  subtyping,  the  equivalence  relationship  between  terms  is  de¬ 
pendent  on  the  type  context:  for  example  the  objects  Ui  =  2,  ^2  =  4]  and 
[^1  =  <;x.{x.lz),l2  =  ”foo”,Z3  =  2]  are  equal  at  type  [/i  :  Int],  because  the 
only  possible  observations  at  this  type  are  on  field  li,  where  the  two  objects 
have  the  same  value.  This  is  precisely  why  types  and  subtypes  are  usually 
interpreted  in  partial  equivalence  relationships  (PERs),  which  express  exactly 
this  relation;  however  PERs  require  denotational  domains  to  be  built  from. 
In  this  section  we  show  how  this  can  be  done  in  our  operational  framework 
through  a  type  indexing  of  the  subsumption  relation. 

Definition  6.1  [Relevant  contexts]  A  context  C[—\  is  relevant  iff  (a  ft'  ==> 
C[a]  fl)  and  C[s\  -I)-.  The  set  of  relevant  contexts  is  written  C. 

The  idea  here  is  that  a  context  is  irrelevant  when  no  observation  can  be 
made  about  the  term  filling  the  hole.  The  first  condition  ensures  that  di¬ 
vergence  at  the  hole  is  propagated  to  the  outer  level.  The  second  condition 
rules  out  the  contexts  which  are  always  divergent,  because  these  also  hide  any 
observation  from  the  hole. 

Lemma  6.2 

Cl-l  e  C  =!.  C[£lt 

Proof.  By  contradiction,  showing  that  if  -i(C[£]t)  then  ^  (C'i— ]  €  C).  This 
is  done  by  induction  on  the  length  of  the  reduction  C{e]  A  v,  comparing  at 
each  step  with  Cfflj.  □ 

Definition  6.3  [Type-dependent  Contexts] 

Ct  =  {C'[— ]  e  C|Va  G  t,  ■■'(C'[a]t)} 

Lemma  6.4  (i)  Cj.  =  C 

(ii)  Ct  =  0 

(iii)  Cr\f  =  {C'H|Va,3n,C'H  A  a"+i} 

(iv)  t<Zu  ==^  C„  C  Ct 

Proof. 

(i)  for  every  relevant  context  C[—\  and  divergent  term  a  €  -L,  C[a]  ff  and 
therefore  -i(C'[a]t). 

(ii)  £  G  T  and  every  relevant  context  filled  with  e  is  erroneous  (Lemma  6.2). 

(iii)  T\S  contains  both  objects  and  functions.  Therefore  C[—\  cannot  con¬ 
tain  a  subterm  of  shape  ([— ]jB[— ]),  because  the  hole  could  be  filled  by 
an  object  and  the  /?  reduction  would  yield  an  error.  Conversely,  the  hole 
cannot  either  participate  in  a  a  or  v  reduction.  Therefore  the  only  re¬ 
ductions  involving  the  hole  must  be  v  reductions.  Finally  C\—\  cannot 
take  a  to  o°  because  then  it  would  be  irrelevant. 
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(iv)  If  C\-\  G  C„  then  Vo  G  m, -i(C'[a]t);  but  then  Va  G  -'(C'[a]t)  because 
t  C  u;  therefore  C[—]  G  C*. 


□ 


Definition  6.5  [Type-dependent  subsumption] 

a  Ef  6  {a^betA  (VC'[-]  G  Ct,  ^[ajt  (^[fe]t)) 

Lemma  6.6  (i)  =  (E) 

(ii)  (St)  =  r  X  r 

(iii)  (Erpop)  =  (T\£)x{T\S) 

(iv)  i  C  ti  =>  ((g,)  C  (g„)) 

Proof.  Direct  consequences  of  Lemma  6.4.  D 

Now  we  overload  the  notation  to  define  a  family  of  subsumption  relations 
indexed  by  syntactic  types  (as  opposed  to  the  semantic  types  used  above). 

Definition  6.7  [Syntactic  type-dep.  subsumption] 

a  ^:T,T,  ^  ®  ^Ti[T]«  b 

Lemma  6.8  (i)  Va,  6  G  T"'^^a  b 

(ii)  Va,6Gr"+'\5,aE^+i,,„6 

(iii)  a  E-+V,,  b  ^  Wee  Ti[T]-,  (ac)  m,r,  (be) 

(iv)  LetT  =  [ii :  Ti*^-^] .  a  EjJ^  b  ^  Wi  el, 

d.li  b.l{/\ 

(c[x  :=  6]  €  Ti[Ti];+‘  =!■ 

(a4=^i  =  ex.c)  {b^li  =  -iar.c)) 

(v)  «  ^vtL:T)u,v  «  Vt  C  Ti[T]^+i,a  b 

(vi)  a  ^j'^x<:T)U,r)  ^  b 

(vii)  a  Wlix^T,t]  b  < — <  a  ^T[X:=iiX.T],t)  b 

Proof.  Double  induction  on  the  shape  of  types  and  on  the  index  n.  □ 

Definition  6.9  [Typed  equalities]  The  interpretation  of  typed  equalities  is: 
Ti[r  h  a  -H-  6  :  T]  =  Wr),a  [=T,  Vn,  {aa  ba) 

Notice  that  this  interpretation  accounts  for  open  objects  and  open  types. 
Lack  of  space  prevents  us  from  checking  the  complete  set  of  equational 
rules  of  [2].  However  it  is  worth  noticing  that  for  most  of  them  we  can  take 
advantage  of  Lemma  6.6:  if  we  are  able  to  prove  a  =  b  then  a  ■<r¥b\T  at  any 
T.  This  in  particular  covers  all  “Eval”  rules  of  [2],  because  a  A  6  =»  a  =  b 
(Property  3.3).  So  we  will  concentrate  on  a  few  interesting  rules  that  are  more 
specifically  related  to  subtyping.  These  are  displayed  in  Figure  7.  The  first 


15 


Dami 


T  =  [Zi  :  r  =  Ui  : 

(EqSub  Obj)  r,  a;:  Thai  :Ti  Vi  G  /  r,a; :  T' h  a^- :  Tj  Vj  G  J 
r  h  [/i  =  'H-  Ui  =  :  T 

r,X  <:T\-a^b:U 


(Eq  V  Intro) 
(Eq  V  Elim) 


r  h  o  ^  6  :  V(X  <:  r)t/ 
rhao6:V(X<:r)[/  T  h  T' <:  T 


(Eq  3  Intro) 
(Eq  3  Elim) 


T\-a<r^b:U[X  —  T'] 
r\-a<^b:U[X  :=r]  E  h  T'  <:  T 
r  h  a  O  6  :  3(X  <:  T)U 
T\- a  b  :3iX  <:T)U  r,X  <:T,x  :  U  c  d  :V 
r  h  c[x  :=  a]  -H-  d[x  :=b]  :V 


Fig.  7.  Some  equational  rules 

one  is  taken  from  [2].  The  other  rules  have  to  do  with  second-order  types 
and  subtyping;  similar  rules  can  be  found  in  the  literature  for  explicitly  typed 
systems  (system  F<),  but  to  the  best  of  our  knowledge  the  present  formulation 
for  implicitly  typed  systems  is  new. 

Theorem  6.10  The  rules  of  Figure  7  are  sound. 

Proof.  (Eq  Sub  Obj):  one  direction  comes  directly  from  the  untyped  sub¬ 
sumption  (Example  3.8,  item  3).  For  the  other  direction,  it  suffices  to  observe 
that,  for  any  rj,  contexts  in  can  only  use  names  in  {Zi|i  G  /}.  (V  and 

3  rules):  first  observe  that  \/r],Ti[U[X  :=  T]],,  =  Ti[C/],,[Xh^Ti[T],,];  second,  for 
any  logical  predicate  P{i])  we  have  the  following  equivalence: 

V77  [=  (T,X  <:  T).Piv)  =  VV  1=  r.Vt  C  Tin>. P{r]'[X  ^  t]) 

Taking  advantage  of  these  facts,  for  example  if  we  take  P{'r])  =  Vn,  a  b 
we  immediately  get  a  soundess  proof  for  for  (Eq  V  Intro).  Other  rules  are 
handled  similarly.  □ 

7  Structural  subtyping 

In  the  previous  section,  subtyping  was  interpreted  as  set  inclusion.  This  is 
quite  close  in  spirit  to  the  two  other  interpretations  found  in  the  literature, 
namely  coercion  functions  [6]  or  inclusions  between  partial  equivalence  rela¬ 
tions  (PERs)  [7].  However  it  also  suffers  from  the  same  problem,  first  explained 
in  [7]:  the  bounded  polymorphic  type 

V(X  <:  T)X  X 
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can  only  contain  the  identity  function.  Intuitively  this  conies  from  the  fact 
that  for  every  member  a  of  T  there  is  a  semantic  subtype  of  T  containing 
only  that  single  member,  and  then  the  function  can  do  nothing  but  map  that 
member  to  itself.  This  is  annoying  because  a  function  like 

Xx.x^l  =  <;y.not(x.l) 

cannot  be  assigned  type 

\/X  <:  U  :  Bool]  .X  ^  X 

Even  if  there  is  no  syntactic  type  [/  ;  True],  there  is  an  ideal  {a  |  a.l  E 
true}  contained  in  Bool  at  which  the  specification  X  ^  X  is  unsound.  In 
consequence  there  is  no  way  to  express  in  the  type  that  this  function  leaves 
all  fields  other  than  I  untouched. 

Several  approaches  have  been  taken  to  fix  the  problem.  As  already  noted 
in  [7],  the  problem  comes  from  the  fact  that  the  semantics  contains  “too  many 
subtypes”,  typically  many  more  than  can  be  defined  in  the  type  syntax.  One 
possibility  then  is  to  drop  the  denotational  semantics  altogether.  Chapter  16 
of  [2]  takes  such  an  approach:  it  introduces  stronger  rules  called  “structural 
rules”  which  take  advantage  of  the  fact  that  all  operations  on  objects  preserve 
some  implicit  structure;  these  rules  are  unsound  in  the  denotational  semantics, 
but  are  proved  to  be  operationally  sound.  Another  possibility  is  to  fix  the  se¬ 
mantic  interpretation  of  subtyping.  This  program  is  carried  out  in  [20],  where 
subtyping  is  restricted  to  pointwise  equality  on  fields  between  “record  PERs”; 
however  this  interpretation  prohibits  depth  subtyping  on  records,  which  is 
somewhat  unsatisfactory  because  intuitively  this  form  of  subtyping  is  struc¬ 
tural.  Hofmann  and  Pierce  [13]  have  a  more  general  approach  where  the 
statement  T  <:  U  is  interpreted  as  a  standard  coercion  c’.T-^U  together 
with  an  overwrite  function  put\T,  U]  :  T  U  U  which  updates  the  “f/ 
part”  of  an  element  of  T  without  changing  the  “remaining  part”.  However 
this  approach  only  works  in  cases  of  “positive  subtyping”,  since  there  is  no 
function  dual  to  put[T,  U]  to  go  down  in  the  type  hierarchy. 

7.1  Structural  subtyping  as  embedding-projections 

Here  we  propose  a  new  interpretation  of  subtyping  by  embedding-projection 
pairs,  very  similar  in  spirit  to  the  maps  used  in  domain  theory  for  solving  recur¬ 
sive  equations  through  inverse  limit  constructions.  The  embedding  t  u 
from  a  subtype  to  its  supertype  is  just  an  inclusion  map,  so  in  the  following 
there  is  no  need  to  mention  it  explicitly.  By  contrast  the  projection  4-“:  u  t 
has  to  “preserve  structure” :  the  image  must  be  equal  to  the  argument  at  type 
u. 

Definition  7.1  [structural  inclusion] 

tQ.u  t  C  It  A  3  4^:  u  -)■  t,  Va  e  It,  4-“  (®)  =  niin({6  e  t\b  =u  a}) 

The  essential  condition  here  is  that  for  every  a  E  u  there  must  be  a  6  G  t 
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(struct  —  forall) 


(struct  —  exists) 


T,X  <lT\-Ui<iU2 
r  h  V(X  <  T)Ui  <1,  V(X  <l  T)U2 
T,X  <lThUi<iU2 
r  h  3(X  <  T)Ui  <l  3(X  <i  T)U2 


Fig.  8.  Structural  subtyping  for  quantified  types 

such  that  b  =„  a.  The  canonical  choice  of  the  minimal  element  is  a  secondary 
condition  which  proves  to  be  convenient  for  dealing  with  quantified  types. 

Before  proceeding  with  our  calculus  it  is  worth  considering  informally  why 
subtyping  is  not  always  structural.  Consider  examples  such  as  [1 ...  10]  <: 
[1...20]  or  True  <:  Bool.  These  make  sense  as  subset  inclusion,  but  the 
only  way  to  map  every  element  of  the  supertype  to  an  element  of  the  subtype 
is  the  constant  function  Xx.Q,  which  loses  all  information  about  its  argu¬ 
ment;  therefore  the  “structure”  of  the  supertype  is  lost.  Similarly,  the  rules 
T  OU  <:Tor_L  <:Tin  systems  with  intersection  types  or  bottom  types 
are  non-structural.  Finally,  since  universal  and  existential  quantification  are 
interpreted  as  intersection  and  union,  the  subtyping  rules  forall  and  exists  in 
Figure  3  also  break  structure.  Therefore  it  is  not  possible  to  just  keep  the 
system  of  Section  4  and  reinterpret  <:  as  Q.. 

A  system  involving  both  subtyping  relations  is  perfectly  conceivable:  it 
suffices  to  add  a  distinction  in  the  type  syntax  between  ordinary  subtyping 
statements  T  <:  U  and  structural  statements  T  <1  U.  Then  in  addition  to 
the  ordinary  quantified  types  we  also  would  have  structurally  quantified  types 
V(X  <4-  T)U  and  3(X  Cj,  T)U,  with  the  obvious  interpretation 

Ti[v{jr  <i  r)c/i;+>  =  agTunr-  TiMSxU.i 

Ti[3{X  <1- 

However  even  if  the  semantic  apparatus  is  ready,  it  is  not  clear  whether  having 
two  distinct  notions  of  subtyping  simultaneously  is  a  desirable  feature.  The 
advantage  of  structural  subtyping  is  that  it  validates  some  more  powerful 
typing  rules,  like  the  (val  structural  update)  rule  shown  below.  On  the  other 
hand  it  forbids  some  “atomic  subtyping”  rules  such  as  True  <;  Bool  or 
Posint  <:  Int.  As  discussed  here,  having  both  is  possible,  but  at  the  cost 
of  a  greater  complexity  in  the  type  system.  Choosing  the  most  appropriate 
solution  is  a  matter  of  language  design.  Here  we  will  briefly  discuss  a  system 
with  structural  subtyping  only. 

Definition  7.2  [Structural  subtyping]  The  system  of  structural  subtyping  de¬ 
fines  judgements  of  shape  T  T  <1  U;  it  is  obtained  from  the  system  of 
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Section  4  by 

(i)  replacing  subtyping  assumptions  X  <:  T  in  F  by  structural  subtyping 
assumptions  X  <\.T\ 

(ii)  replacing  <:  by  <j,  in  the  rules  of  Figure  3; 

(iii)  replacing  rules  (Jorall)  and  (exists)  in  Figure  3  by  the  weaker  version 
given  in  Figure  8. 

For  this  system  we  obviously  reinterpret  the  statement  t;  [=  F  as  Ti[X];j  Q, 
Ti[T];,  whenever  (X  <\.T)  £  F. 

Theorem  7.3  (Soundness  of  structural  subtyping) 

ri-r<4C^=^Vj7(=F,  Ti[r]^  a  Ti[c/]^ 


Proof.  Induction  on  the  proof  oiT  \-T  <IU.  For  each  subtyping  rule  used 
we  exhibit  the  witness  function  which  will  be  abbreviated  as  4^. 


•  case  (top):  4^^^=  \x.Q. 

•  case  (refl):  \.x=  ^x.x. 

•  case  (env):  from  the  assumption  rj  T,X  <IT  there  exists  a  projection 
|Ti[r], 

•  case  (arrow):  A/,  o/o 

•  case  (obj):  =  Q  (J  =  {ji . ..jk}) 

•  case  (forall):  we  know  that  Q,  Ti[T]^,3  4'Tl[aj”[x!l«]  Therefore  we 

can  build 


I  'i{X<XT)V 


Pj  I  Ti[V],[XM.t] 

I  I  4Ti[a],[x«t] 


tCl.Ti[T], 

By  the  fact  that  each  projection  function  canonically  chooses  the  minimal 
element  in  its  codomain,  their  intersection  is  well-defined  and  satisfies  the 
conditions  of  Definition  7.1. 


•  case  (exists):  like  the  preceding  case,  taking  (J  instead  of  H- 

•  case  (rec):  using  the  premice  F,  X  <IY  \-  T  <|.  t/,  we  show  by  induction 

Tifwy.C/l” 

on  n  that  the  family  of  projections  4'Ti[/tXT]^  well-defined.  Then  the 
projection  4'J!xt  union  of  such  projections. 

•  cases  (fold),  (unfold): 

□ 


Corollary  7.4  The  “val  structural  update”  rule  of  [2]  is  sound: 

T\-a:T  F  h  T  cj,  [/i  :  T,x:T\-b:Tj  jel 

F  h  a^lj  =  <;x.b  :  T 
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Proof.  Suppose  r),a  \=r  and  ba[x  ;=  a]  G  Ti[Tj];,.  Let  a'  =  a^lj  =  ^x.b  and 
a"  (o'):  we  must  have  o"  G  Ti[T],,  and  o"  Hence  T 

is  closed  under  updates  of  type  Tj  at  Ij.  D 

Like  [20],  we  now  show  an  isomorphism  which  proves  that  type  V(X  <], 
U  :  T'])X  X  contains  more  functions  than  just  the  identity. 

Theorem  7.5  The  types  'i{X  c^U  T'\)X  X  and  T  are  isomorphic. 

Proof.  Consider  functions 

F  =  \f.\x.{f{U^x])).l 
G  =  Xf.Xx.x^l  =  f{x.l) 

It  is  easy  to  see  that  FoG  =  GoF  =  l,  and  that  F  :  (y{X  <[,  [/ :  T])X  —>• 
X)  ->  (T  ->  T).  By  contrast  structural  subtyping  is  required  for  the  reverse 
typing:  G  :  (T  -^T)  -y  (V(A’  <4  [^ :  T]  )X  ^  X)  is  only  derivable  if  we  have 
the  (val  structural  update)  rule  above.  n 

8  Conclusion 

Thanks  to  several  recent  works,  operational  techniques  are  regaining  consider¬ 
able  interest.  Results  such  as  fixpoint  induction,  which  once  were  only  provable 
through  denotational  means,  are  now  shown  with  operational  bisimilarities 
[21].  However  in  these  works  subtyping  was  seldom  taken  into  account.  The 
framework  proposed  in  [10],  introducing  an  explicit  error  constant  e  which  be¬ 
comes  the  top  element  of  the  semantic  lattice,  can  remedy  to  this  deficiency. 
By  applying  it  here  to  the  object  calculus  of  Abadi  and  Cardelli,  we  have 
demonstrated  that  some  complex  aspects  of  the  abstract  framework  (namely 
the  defintion  of  erroneous  terms)  can  be  greatly  simplified  when  working  with 
a  concrete  calculus.  Furthermore  we  have  introduced  a  number  of  technical 
innovations  or  improvements  to  previous  work: 

•  rules  for  bounded  second-order  types  in  an  implicitly  typed  system; 

•  an  operational  interpretation  of  typed  equalities  which  deals  with  open 
terms  and  open  types; 

•  a  semantic  interpretation  of  “structural  subtyping” ; 

•  a  “super-top”  type  which  improves  the  typing  power  of  the  system  without 
impairing  type  soundness. 


Acknowledgements 

A  previous  draft  of  this  paper  received  very  detailed  comments  from  anony- 
ous  referees;  these  were  extremely  useful  to  improve  the  quality  of  the  paper. 
Comments  from  various  participants  to  the  HOOTS  II  workshop  are  also  grate¬ 
fully  acknowledged. 


20 


Dami 


References 

[1]  Samson  Abramsky  and  C.-H.  Luke  Ong.  Full  Abstraction  in  the  Lazy  Lambda 
Calculus.  Information  and  Computation,  105:159-267,  1993. 

[2]  Martin  Abadi  and  Luca  Cardelli.  A  Theory  of  Objects.  Springer-Verlag, 
Monographs  in  Computer  Science,  1996. 

[3]  Martin  Abadi,  Benjamin  Pierce  and  Gordon  Plotkin.  Faithful  Ideal  Models  for 
Recursive  Polymorphic  Types.  Int.  J.  of  Foundations  for  Computer  Science, 
2(1):1-21,  1991. 

[4]  Roberto  Amadio  and  Luca  Cardelli.  Subtyping  Recursive  Types.  ACM  Trans, 
on  Prog.  Lang  and  Systems,  15(4):575-631,  1993. 

[5]  Henk  Barendregt.  The  Lambda-Calculus,  its  Syntax  and  Semantics.  Studies  in 
Logic  and  the  Foundations  of  Mathematics,  North-Holland,  1984. 

[6]  Val  Breazu-Tannen,  Thierry  Coquand,  Carl  A.  Gunter,  and  Andre  Scedrov. 
Inheritance  as  Implicit  Coercion.  Information  and  Computation  93:172-221, 
1991.  Also  in  [12],  pp  197-245. 

[7]  Kim  Bruce  and  Giuseppe  Longo.  A  Modest  Model  of  Records,  Inheritance,  and 
Bounded  Quantification.  Information  and  Computation  87:196-240,  1990.  Also 
in  [12],  pp  151-195. 

[8]  Felice  Cardone  and  Mario  Coppo.  Two  extensions  of  Curry’s  Type  Inference 
System.  In  Logic  and  Computer  Science,  P.  Odifreddi(ed),  pp  19-75.  Academic 
Press,  1990. 

[9]  Laurent  Dami.  A  Lambda-Calculus  for  Dynamic  Binding.  Theoretical  Comp. 
Sc.  192(2):201-231,  Feb  1998. 

[10]  Laurent  Dami.  Labeled  Reductions,  Runtime  Errors,  and  Operational 
Subsumption.  Extended  abstract  in  Proc.  ICALP’97,  LNCS,  Springer-Verlag, 
1997.  Expanded  version  in  Objects  at  Large,  Technical  Report,  University  of 
Geneva,  1997,  available  firom  http://cuiwww.imige.ch/~dami/publis.html. 

[11]  Andrew  Gordon  and  Gareth  Rees.  Bisimilarity  for  a  First-Order  Calculus  of 
Objects  with  Subtyping.  Technical  Report  386,  Computer  Laboratory,  University 
of  Cambridge,  January  1996,  available  at  http://www.cl.cam.ac.uk/  adg. 
Technical  summary  in  Proceedings  23rd  ACM  POPL,  Jan  1996,  pp  386-395. 

[12]  Carl  A.  Gunter  and  John  C.  Mitchell,  eds.  Theoretical  aspects  of  object-oriented 
programming:  types, semantics,  and  language  design.  MIT  Press,  Foundations  of 
computing  series,  1994. 

[13]  Martin  Hofmann  and  Benjamin  C.  Pierce.  Positive  subtyping.  Information  and 
Computation,  126(l):ll-33,  10  April  1996. 

[14]  D.  J.  Howe.  Equality  in  lazy  computation  systems.  In  Proc.  jth  IEEE  Symp. 
on  Logic  in  Comp.  Sc.,  pp  198-203,  1989. 


21 


Dami 


[15]  Trevor  Jim  and  Albert  R.  Meyer.  Full  Abstraction  and  the  Context  Lemma. 
SIAM  J.  on  Computing  25(3):663-696,  June  1996. 

[16]  Marina  Lenisa.  Semantic  Techniques 

for  Deriving  Coinductive  Characterizations  of  Observational  Equivalences  for 
Lambda-Calculi.  Proc.  TLCA’97,  pp  248-266.  LNCS  1210,  Springer- Verlag, 
1997. 

[17]  Luigi  Liquori.  An  Extended  Theory  of  Primitive  Objects:  First  Order  System. 
Proc.  ECOOP’97,  pp  146-169,  LNCS  1241,  Springer-Verlag,  1997. 

[18]  David  MacQueen,  Gordon  Plotkin  and  Ravi  Sethi.  An  Ideal  Model  for  Recursive 
Polymorphic  Types.  Information  and  Control,  71:95-130,  1986. 

[19]  Ian  A.  Mason,  Scott  F.  Smith  and  Carolyn  L.  Talcott.  From  Operational 
Semantics  to  Domain  Theory.  Information  and  Computation,  128:26-47,  1996. 

[20]  Erik  Poll.  System  F  with  Width-subtyping  and  Record  Updating.  Proc. 
Intemat.  Symp.  on  Theoret.  Aspects  of  Comp.  Software,  Sendai,  Japan.  LNCS, 
Springer-Verlag,  1997. 

[21]  Scott  Smith.  The  Coverage  of  Operational  Semantics.  In  Higher  Order 
Operational  Techniques  in  Semantics,  A.  Gordon  and  A.  Pitts,  editors, 
Cambridge  University  Press,  1998. 

[22]  M.  Takahashi.  Parallel  Reductions  in  A-calculus.  Information  and  Computation, 
118(1):120-127,  1995. 


22 


Monadic  Type  Systems: 

Pure  Type  Systems  for  Impure  Settings 
(Preliminary  Report) 


Gilles  Barthe  ^ 

Chalmers  Tekniska  Hdgskola,  Institutionen  for  Datavetenskap,  Eklandagatan  86,  Goteborg, 
S-412  96  Sweden,  gillesb0cs.chalmers.se 

John  Hatcliff  ^ 

Oklahoma  State  University,  Department  of  Computer  Science,  219  Math  Sciences,  Stillwater, 
OK,  USA,  74078,  hatcliff0a.cs.okstate.edu 

Peter  Thiemann 

Dept,  of  Computer  Science,  University  of  Nottingham,  University  Park,  Nottingham  NG7 

2RD,  England,  pjt0cs.nott.ac.\ak 


Abstract 

Pure  type  systems  and  computational  monads  are  two  parameterized  frameworks  that  have 
proved  to  be  quite  useful  in  both  theoretical  and  practical  applications.  We  join  the  foundational 
concepts  of  both  of  these  to  obtain  monadic  type  systems.  Essentially,  monadic  type  systems 
inherit  the  parameterized  higher-order  type  structure  of  pure  type  systems  and  the  monadic 
term  and  type  structure  used  to  capture  computational  effects  in  the  theory  of  computational 
monads.  We  demonstrate  that  monadic  type  systems  nicely  characterize  previous  work  and 
suggest  how  they  can  support  several  new  theoretical  and  practical  applications. 

A  technical  foundation  for  monadic  type  systems  is  laid  by  recasting  and  scaling  up  the  main 
results  from  pure  type  systems  (confluence,  subject  reduction,  strong  normalisation  for  particular 
classes  of  systems,  etc.)  and  from  operational  presentations  of  computational  monads  (notions 
of  operational  equivalence  based  on  applicative  similarity,  co-induction  proof  techniques). 

We  demonstrate  the  use  of  monadic  type  systems  with  case  studies  of  several  call-by- value  and 
call-by-name  systems.  Our  framework  allows  to  capture  the  restriction  to  value  polymorphism 
in  the  type  structure  and  is  flexible  enough  to  accommodate  extensions  of  the  type  system, 
e.g.,  with  higher-order  polymorphism.  The  theoretical  foundations  make  monadic  type  systems 
well-suited  as  a  typed  intermediate  language  for  compilation  and  specialization  of  higher-order. 
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strict  and  non-strict  functional  programs.  The  monadic  structmre  guarantees  sound  compile-time 
optimizations  and  the  parameterized  type  structure  guarantees  sufficient  expressiveness. 

Key  words:  Functional  programming,  polymorphism,  pure  type  systems, 
monads,  operational  semantics. 
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1  Introduction 


The  compilation  of  typed  higher-order  programming  languages  requires  the  use  of  inter¬ 
mediate  languages.  This  is  due  to  the  large  conceptual  gap  between  source  and  target 
languages  in  such  a  translation.  In  addition,  the  use  of  an  intermediate  language  yields 
a  S3mergistic  effect  since  common  backends  and  program  transformations  may  be  shared 
among  several  source  languages.  Therefore,  a  large  amount  of  flexibility  in  terms  of  oper¬ 
ational  properties  as  well  as  typing  properties  is  required  from  an  intermediate  language. 

Recent  work  in  compilation  has  produced  a  number  of  compile-time  frameworks  that 
either  stress  the  operational  properties  or  the  typing  properties.  But  none  of  the  frame¬ 
works  considered  so  far  offers  parametricity  in  both  respects.  Our  aim  is  to  reconcile  these 
hitherto  separate  concerns  by  joining  in  a  single  framework  the  fundamental  concepts  of 
pure  type  systems  and  those  of  computational  monads. 


Computational  monads: 

Moggi’s  theory  of  computational  monads  as  embodied  by  his  computational  metalan¬ 
guage  parameterizes  semantic  specifications  by  a  notion  of  computation  (state  transfor¬ 
mation,  I/O,  etc.)  [36].  Terms  in  the  metalanguage  can  be  reduced  without  regard  to 
computational  effects  —  even  without  specifying  their  nature  —  provided  that  they  can 
be  expressed  with  a  monad.  In  addition,  the  metalanguage  explicitly  orders  all  operations 
with  computational  effects.  A  wide  range  of  evaluation  orders  (call-by-name,  call-by- value, 
and  mixed  strategies)  can  be  encoded  by  choosing  a  suitable  translation  into  the  meta¬ 
language.  Thus,  the  metalanguage  provides  an  evaluation- order  independent  framework 
for  describing  evaluation  and  reasoning  in  the  presence  of  computational  effects. 

The  computational  metalanguage  has  been  used  successfully  in  a  number  of  applica¬ 
tions  including  compiling  transformations,  intermediate  languages  for  partial  evaluation, 
denotational  foundations  for  languages  with  I/O,  and  structuring  functional  programs 
with  effects  {e.g.,  [14,16,21,27,28,32,40,50]).  The  benefits  of  the  metalanguage  are  as 
follows. 

Increased  modularity:  Compilation,  partial  evaluation,  and  semantics  can  be  specified 
in  terms  of  the  metalanguage:  all  computational  aspects  of  the  source  language  are 
captured  in  the  metalanguage;  no  extra  information  is  necessary. 

Correctness:  The  framework  guarantees  the  soundness  of  compile-time  reductions  in 
the  presence  of  computational  effects. 

Genericity:  The  metalanguage  is  general  enough  to  encode  the  structure  of  a  variety  of 
source  languages  by  choosing  a  suitable  translation.  The  resulting  translated  programs 
are  in  monadic  normal  form  [28]  —  a  generalization  of  A-normal  forms  [16],  where  each 
intermediate  result  is  named.  This  form  is  particularly  suited  to  compiling. 

However,  most  applications  deal  with  untyped  or  simply-typed  versions  of  the  meta¬ 
language  and  do  not  support  parametricity  of  the  type  structure. 


4 


Pure  type  systems: 

Pure  type  systems  (PTS)  [4]  are  a  generic  framework  to  define  type  systems  and  logics. 
Examples  are  LF,  and  the  Calculus  of  Constructions.  They  provide  the  theoretical 

foundation  for  proof  assistants  and  modern  programming  language  type  systems.  Subtle 
differences  between  the  systems  can  be  described  by  varying  the  specification  upon  which 
the  framework  is  parameterized. 

Compactness  and  parametricity  make  PTSs  an  attractive  framework  for  typed  interme¬ 
diate  languages  [31].  This  builds  on  a  well-established  practice  of  using  subsystems  of  F^j 
in  compiling  polymorphic  programming  languages  like  ML  or  Haskell  [23,26,35,39,46,47]. 
It  is  by  now  an  accepted  fact  that  type  information  is  beneficial  in  all  phases  of  compi¬ 
lation  and  program  transformation.  PTSs  are  exceptionally  well  suited  because  of  the 
following  features. 

Economy:  Since  terms  and  types  are  conflated  in  one  syntactic  category,  the  same  func¬ 
tions  can  be  used  for  their  manipulation. 

Extensibility:  The  intermediate  language  is  robust  with  respect  to  changes  to  the  type 
system  of  the  source  language:  extensions  to  the  type  system  usually  amount  to  chang¬ 
ing  only  the  specification  of  the  PTS. 

Checkability  Being  explicitely  typed,  many  PTSs  have  a  decidable  type-checking.  There¬ 
fore  all  compile-time  transformations  can  be  type  checked  and  thus  debugged. 

In  many  of  these  applications,  PTSs  (whose  semantics  are  free  from  computational  effects) 
are  being  used  in  settings  where  computational  effects  are  ubiquitous.  Whereas  the  PTS 
framework  provides  adequate  treatment  of  the  type  structure,  it  does  not  ensure  sound 
treatment  of  effects.  This  stems  from  the  fact  that  /^-conversion  is  the  foundational 
notion  of  equality  in  PTSs.  As  a  consequence,  a  PTS-based  intermediate  language  (such 
as  one  might  use  for  treating  ML)  must  impose  ad  hoc  restrictions  to  ensure  soundness. 
Furthermore,  it  seems  difficult  to  use  a  PTS-based  language  for  languages  that  explicitly 
control  the  evaluation  order.  This  situation  arises  in  a  Haskell  compiler  after  strictness 
and/or  totality  analysis. 


Monadic  type  systems: 

Monadic  type  systems  (MTSs)  join  the  concepts  of  the  computational  metalanguage 
and  of  pure  type  systems.  They  inherit  the  parameterized  higher-order  type  structure 
of  pure  type  systems  and  the  monadic  term  and  type  structure  used  to  capture  com¬ 
putational  effects  in  the  theory  of  computational  monads.  The  combination  shares  the 
above-listed  advantages  of  both  frameworks — except  for  type-checking  which  is  undecid- 
able  for  languages  that  include  dependent  types — and  provides  some  additional  features. 
For  example,  an  MTS  specification  can  enforce  the  restriction  to  value  polymorphism  [34] 
by  type  checking  the  intermediate  language.  Furthermore,  it  is  possible  to  encode  other 
approaches  to  the  sound  treatment  of  effects  in  the  presence  of  polymorphism  (e.g.,  poly¬ 
morphism  by  name  [33]). 
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1 . 1  Contributions 


This  paper  takes  a  first  step  towards  combining  the  fundamental  concepts  of  pure  type 
systems  and  computational  monads  and  towards  developing  operational  theories  for  A- 
calculi  with  dependent  types. 

•  MTSs  combine  the  fundamental  concepts  of  pure  type  systems  and  computational  mon¬ 
ads,  thus  providing  a  typed  intermediate  framework  that  offers  parametricity  with  re¬ 
spect  to  type  disciplines  and  computational  effects.  ® 

•  The  main  technical  properties  of  PTSs  (confluence,  subject  reduction,  strong  normali¬ 
sation  for  particular  classes  of  systems,  etc.)  are  recast  and  proved  for  MTSs. 

•  The  operational  properties  of  the  computational  metalanguage  (notions  of  operational 
equivalence  based  on  applicative  similarity,  co-induction  proof  techniques)  are  recast 
and  proved  for  MTSs  where  the  notion  of  computation  is  non-termination  as  expressed 
by  the  lifting  monad. 

•  A  detailed  case  study  (SML’97  with  value  polymorphism)  demonstrates  a  specific  in¬ 
stance  of  the  MTS  framework  which  captures  the  operational  and  typing  properties 
that  are  desirable  in  a  typed  intermediate  representation  for  SML’97.  This  particular 
language  can  serve  as  a  basis  for  compiling  ML  and  also  for  specialization  of  ML.  It 
is  noteworthy  that  specialization  with  respect  to  values  and  specialization  with  respect 
to  types  is  indistinguishable  in  the  language,  which  leads  to  some  simplification  inside 
a  compiler /specializer.  On  the  other  hand,  the  monadic  structure  is  indispensable  to 
ensure  the  soundness  of  transformations  inside  a  compiler/specializer. 

1.2  Overview 

The  rest  of  the  paper  is  organized  as  follows.  Section  2  presents  the  basic  definitions  of 
monadic  type  systems.  Section  3  provides  intuition  and  illustrates  how  the  MTS  frame¬ 
work  can  be  used  to  describe  many  systems  and  concepts  appearing  in  the  literature. 
Section  4  reviews  technical  properties  of  monadic  type  systems.  Section  5  is  devoted  to 
the  operational  semantics  of  monadic  type  systems. 

Section  6  assesses  the  applicability  of  MTS  and  compares  them  with  related  work. 
Section  7  gives  conclusions  and  future  work. 

Throughout  the  paper,  we  assume  some  basic  knowledge  of  computational  monads 
and  pure  type  systems. 


2  Syntax  of  Monadic  Type  Systems 

In  PTSs,  different  typed  A-calculi  are  generated  by  varying  PTS  parameters  called  spec¬ 
ifications  that  consist  of  sorts,  axioms  and  rules.  Sorts  provide  the  type  universes  of 
the  calculus.  Axioms  provide  a  “membership”  relation  between  universes,  while  rules 
determine  which  function  types  may  be  formed  and  in  which  universe  they  live. 


®  Both  pure  type  systems  and  the  metalanguage  have  achieved  a  status  of  ‘standards’.  We  do  not  claim 
that  MTSs  inherit  this  status  and  expect  alternative  or  refined  syntaxes  to  arise. 
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Logical  Pure  Type  Systems  [10]  form  a  class  of  specifications  that  feature  a  distin¬ 
guished  sort  *  of  propositions  or  programs,  that  is  required  to  comply  with  several  re¬ 
quirements.  Examples  of  Logical  Pure  Type  Systems  include  systems  in  Barendregt’s 
A-cube  [3,4]  which  are  obtained  from  specifications  that  use  the  sorts  =f=  and  □,  with  the 
axiom  ♦  :  Intuitively,  inhabitants  of  *  are  types  and  inhabitants  of  types  are  programs, 

whereas  inhabitants  of  □  are  kinds  and  inhabitants  of  kinds  are  type  constructors. 

Monadic  Type  Systems  are  based  on  the  same  idea.  The  difierence  is  that  MTSs  also 
include  a  fundamental  concept  from  the  theory  of  computational  monads:  they  distinguish 
between  types  for  values  (completely  evaluated  terms,  or  terms  with  no  computational 
effects)  and  types  for  computations  (terms  with  remaining  effectful  computational  steps). 
Technically,  the  distinction  is  achieved  by  distinguishing  a  sort  of  values  and  a  sort  of 
computations.  As  a  result  of  our  choice,  the  framework  does  not  encompass  every  mean¬ 
ingful  monadic  type  system — in  the  same  way  as  the  class  of  logical  specifications  does 
not  encompass  every  meaningful  pure  type  system — yet  it  allows  for  many  interesting 
systems  to  be  defined. 

Definition  1  (specifications)  A  (MTS)  specification  is  a  tuple  S  =  (5,*”,*®,  .4,7^) 
where 

•  «S  is  a  set  of  sorts; 

•  €  <S  is  the  sort  of  values  and  G  5  is  the  sort  of  computations; 

•  ^  C  ,S  X  <S  is  a  set  of  axioms; 

•  72.  C  <S  X  <S  X  <S  is  a  set  of  product  rules. 

The  above  Definition  does  not  impose  any  requirement  of  the  sorts,  axioms  or  rules  and 
thus  allows  for  specifications  that  violate  the  monadic  characteristics.  These  requirements 
(which  yield  what  we  call  “strictly  monadic  specifications”)  are  postponed  until  Section 
4  and  Section  5. 

Monadic  type  systems  have  a  single  category  of  expressions,  which  are  called  pseudo¬ 
terms.  Pseudo-terms  are  built  from  the  standard  constructors  for  pure  type  systems — 
including  abstraction,  application  and  dependent  product — and  for  monads — including 
unit  and  let-expressions.  In  addition,  pseudo-terms  include  a  data  type  of  natural  numbers 
with  some  basic  operations  and  a  fixpoint  construct  that  give  a  “PCF-like”  presentation 
of  monadic  type  systems.  A  more  general  presentation,  which  falls  out  of  the  scope  of 
this  paper,  would  be  to  include  a  scheme  for  inductive  types,  e.g.  based  on  recent  work 
by  T.  Coquand  [9]. 

Definition  2  (pseudo-terms)  The  set  T  of  pseudo-terms  is  defined  by  the  abstract 
syntax 

r=v|<s|rr|AV:r.r|nv:r.r(iet  vtT^r  in  r|unitr|M  n 
fix  V:r.  r  I  nat  |  \n]  \  succ  T  \  pred  T  |  ifO  T  T  T 
For  technical  convenience,  we  assume: 

(i)  variables  to  be  sorted,  i.e.  V  =  Uses  where  the  V*s  are  pairwise  disjoint  countably 
infinite  sets; 
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(ii)  Barendregt’s  variable  conventions  [2]. 

Substitution,  free  and  bound  variables,  etc.  are  defined  as  usual.  The  notions  of  reduction 
for  monadic  type  systems  are  drawn  from  those  of  pure  type  systems  and  those  of  the 
computational  metalanguage. 

Definition  3  (notions  of  reduction) 

•  yd-reduction  is  defined  as  the  compatible  closure  of  the  rule 

(Ac:  A  M)N^0M{x  :=  N} 

•  //-reduction  is  defined  as  the  compatible  closure  of  the  rules 

let  x:A  4=  (unit  N)  in  M{x  :=  N} 

let  x:A<=  M  in  (unit  x)  M 

let  X2'A2  -4=  (let  xi'.Ai  4=  Mi  in  M2)  in  M3  ->^3  let  xi'.Ai  <=  Mi  in  (let  X2'A2  *4=  M2  in  M3) 
where  in  the  last  rule  it  is  assumed  that  X2  ^  FV(Ai)  U  FV(Mi). 

•  (^reduction  is  defined  as  the  compatible  closure  of  the  rule 

fix  x:M.  N  N{x  :=  fix  x:M.  N} 

•  /-reduction  is  defined  as  the  compatible  closure  of  the  rule 

ifO  [01  M  N 
ifO  [n  -Ml  M  iV  AT 

succ  [nl  — [n-Ml 
pred  [n-f  ll  ->-4  [nl 
pred  [01  [01 

pred  (succ  x)  — x 

•  The  notion  of  mZ-reduction  is  defined  as  the  union  of  P,  t,  (j)  and  //-reductions. 

We  do  not  consider  //-reduction  since  it  is  unsound  for  CPS  translations  and  would  com¬ 
plicate  the  meta-theory.  The  typing  rules  for  MTSs  are  drawn  from  the  rules  of  pure 
type  systems  and  computational  monads.  In  addition,  there  are  rules  for  data  types  and 
fixpoints. 

Definition  4  (derivability) 

•  A  pseudo-context  is  a  finite  (ordered)  list  of  pairs  x  :  A  where  x  G  V  and  A^T.  The 
set  of  pseudo-contexts  is  denoted  by  C  and  the  empty  context  is  denoted  by  ().  The 
domain  of  a  context  T  is 


dom(r)  =  {x  I  G  T.  X  :  f  €  r} 

We  use  r,  A  as  metavariables  ranging  C. 
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structural  rules 


(axiom) 

(si,  S2)  G  A 

0  b  Si  :  S2 

(conversion) 

T  A:B 

r  B':s  B=miB' 

T  \-  A:  B' 

(start) 

T  h  A:s 

a:  €  V*  \  dom(r) 

r,® : 

A  \-  X  :  A 

(weakening) 

T  \-  A:B 

ri-Cis  a;€V*\  dom(r) 

T,x:C  A:  B 

Product  rules 


(product) 


(abstraction) 


(application) 


r  h  ^  :  Si  T,x  :  A  h  B  S2  (si, S2, S3)  €  IZ 
r  h  {UxiA.  B)  :  S3 

r,x:Ah  b:B  F  h  (nx:A.g)  :s 
r  h  )(c:A.b:  Ha::  A.  B 

r  I-  F:{Ux:A.B)  T  h  a  :  .4 
r  h  Fa  :  B{x  :=  a} 


Fig.  1.  Rules  for  Monadic  Type  Systems  (structural  and  product  rules) 
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•  A  judgement  is  a  triple  T  \-  M  :  A  where  F  €  C  and  M,  A  ^T. 

•  The  derivability  relation  h  is  induced  by  the  rules  of  Figures  1  and  2.  If  F  h  M  :  A 
then  F,  M,  A  are  legal. 

•  The  MTS  generated  by  S  is  the  quadruple  AS  =  (T,  C,  —^mi,  !“)• 

The  next  Section  illustrates  the  use  of  the  framework  through  several  instances  of  monadic 
type  systems. 


3  Instances  of  Monadic  Type  Systems 

Each  specification  defines  a  particular  instance  of  a  monadic  type  system.  In  this  section, 
we  explore  specifications  that  characterize  the  images  of  various  translations  that  encode 
evaluation  strategies  in  the  computational  metalanguage.  The  crucial  point,  in  each  case, 
is  the  distinction  between  values  and  computations.  We  illustrate  this  for  some  well- 
studied  simply-typed  languages,  then — in  more  detail — for  a  fragment  of  ML,  and  finally 
for  call-by-name  and  call-by- value  versions  of  F^.  The  latter  one  is  particularly  interesting 
because  it  is  quite  close  to  the  intermediate  language  used  in  the  FLINT/ML  compiler 
project  [45]. 

All  systems  considered  in  this  section  are  related  to  the  A-cube.  They  share  the  set  of 
sorts  and  the  axioms: 

•  A  =  {*^  : 

The  intuition  here  is  that  the  elements  of  are  types  of  values,  which  are  inhabited 
by  effect-free  terms,  whereas  the  elements  of  are  types  of  computations,  which  are 
inhabited  by  terms  that  may  have  computational  effects:  nontermination,  in  the  most 
simple  case.  This  distinction  is  used  to  enforce  the  value  restriction  of  SML’97.  Also 
certain  operational  properties  of  a  term  can  be  proved  just  from  determining  whether  its 
type  has  kind  or  Similarly,  the  elements  of  are  value  kinds,  which  are  inhabited 
by  value  type  constructors,  and  likewise  for 

The  rule  sets  of  the  specifications  considered  in  this  section  do  not  involve  at  all. 
Abstractions  involving  are  found  to  be  sufficient,  even  to  characterize  the  images  of 
call-by-name  translations,  where  we  expect  to  perform  abstraction  over  computations. 
Since  we  do  not  have  a  proof  that  and  □"  can  be  conflated  to  □,  in  general,  we  keep 
the  more  precise  distinction  for  the  time  being. 


3.1  Simply-typed  systems 

Many  systems  of  interest  only  have  product  rules  of  the  form  (si,S2>  *’')>  which  we  write 
as  [si,S2].  They  reflect  the  expected  monadic  typing  of  abstractions  as  values.  Since 
simply-typed  systems  do  not  allow  abstraction  of  types,  the  rules  do  not  contain  and 
□*=. 
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Monad  rules 

(monad) 

T  \-  A: 

r  \-  M  A: 

(unit) 

r  \-  M:A  ri-M^:s 

r  h  unit  M  :  M  A 

(let) 

rhM:M.4  r,i:>ll-W:Mi? 

T  \-  \etx:A^M  \n  N  :M  B  ^  ^  ’ 

Rules  for  natural  numbers 

(nat) 

h  nat : 

(num) 

h  [n]  :  nat 

(succ) 

r  h  M  :  nat 

r  h  succ  M  :  nat 

(pred) 

r  h  M  :  nat 

r  h  pred  M  :  nat 

(test) 

r  h  M  :  nat  T  Ni:MB  F  h  JV2  :  M  S 

r  h  ifO  M  JVi  JV2  :  M  R 

Fixpoint  rule 

(fixpoint) 

r,x:M  A  \-  M  :M  A 

r  h  fixa::M  AM:  M  A 

Fig.  2.  Rules  for  Monadic  Type  Systems  (monads,  naturals  and  fixpoint  rules) 
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Call-by-name: 

Translations  that  encode  call-by-name  evaluation  in  the  metalanguage  yield  functions 
that  map  computations  to  computations  [21, 28,  50].  The  intuition  is  that  arguments 
are  suspended  computations.  Each  variable  access  initiates  evaluation  of  the  suspended 
computation.  There  is  only  one  rule: 


=  {[*",  *1}. 


Call-by-value: 

In  contrast  to  call-by-name,  call-by-value  functions  take  values  as  arguments.  This  is 
enforced  by  allowing  only  abstractions  with  value  types  in  the  domain  position  [28,50]: 


It  is  also  possible  to  encode  call-by-value  in  the  system  generated  by  the  call-by-name 
specification  above.  The  idea  is  to  force  the  evaluation  of  the  argument  first,  then  pass 
the  resulting  value  as  a  thunk  (which  corresponds  to  a  computation,  see  [21,28]). 


Call-by-name  and  call-by-value: 

This  language  provides  a  generic  intermediate  language  for  encoding  both  call-by-name 
and  call-by- value  programs  [28]  and  also  for  strictness  analyzed  call-by-name  programs 
[7, 12].  The  rule  set  consists  of  the  rules  from  both  preceding  cases: 


Full  value  types: 

Some  applications  [13,21]  need  to  distinguish  functions  that  are  trivial  [42]  in  the 
sense  that  their  application  causes  no  computational  effects.  With  the  lifting  monad, 
such  functions  would  be  guaranteed  to  be  total  given  any  appropriately  typed  argument. 
The  following  specification  allows  for  such  functions  by  letting  value  types  occur  in  the 
codomain  position. 

=  {[.”,»•],  [»', »'],  K,  .‘1, 


3.2  Polymorphic  systems  (ML-style) 

In  this  section,  we  investigate  the  translation  of  a  fragment  of  ML  into  a  suitable  MTS. 
We  then  prove  that  the  translation  preserves  typing  and  that  ML  evaluation  is  compatible 
with  MTS-equality  (=mJ)  the  reflexive,  transitive,  symmetric  closure  of  ->m0- 

The  starting  point  for  a  specification  of  an  ML-style  language  is  the  specification  IZobv 
For  concreteness,  we  will  concentrate  on  a  fragment  of  Standard  ML’97  [34].  SML  is  a 
call-by- value  language  with  impure  features  like  references  and  I/O.  In  the  fragment  that 
we  consider  initially,  the  only  effect  is  nontermination.  Hence  the  monad  must  include  the 
lifting  monad.  Later  on,  we  add  stores  and  require  (at  least)  a  combination  of  the  state 
monad  with  the  lifting  monad.  The  full  SML  language  also  includes  exceptions,  I/O,  and 


12 


types 

r  ::=  O'  1  nat  |  r  — >■  r 

type  schemes 

<T  ::=  T  1  Va.cr 

terms 

e  V  \  n 

values 

V  X  \  f  \  i\  Xx.e  \  fix  f.e 

non- values 

n  ::=  e@e  |  let  a;  =  t;  in  e  |  ifO  e  e  e  |  succ  e  |  pred  e 

Fig.  3.  A  Fragment  of  SML’97 

continuations  (in  the  New  Jersey  dialect  of  ML).  These  features  are  not  considered  here, 
but  are  nevertheless  tractable  in  the  framework. 

ML  abstractions  are  modeled  by  the  rule  To  express  type  abstractions,  we 

add  the  rule  [□",  *’']  which  basically  says  that  a  type  scheme  is  also  a  type.  This  setting 
ignores  the  fact  that  ML’s  polymorphism  is  predicative:  in  ML,  type  abstractions  may  be 
nested  inside  of  type  abstractions,  but  not  inside  of  other  type  constructors. 

Predicativity  can  be  recovered  in  at  least  two  ways: 

(i)  Add  a  new  sort  }t  and  use  the  rules  (□",  tt)  and  (□",  K,  }t)  for  forming  type  abstrac¬ 
tions. 

(ii)  Add  an  inclusion  C  in  the  style  of  Harper  and  Mitchell  [25].  Now  type 
abstractions  are  governed  by  the  rule 

Both  approaches  do  not  fit  into  the  present  framework:  the  specification  involving  Jt  is 
not  value-adhering  (see  Definition  26)  and  inclusion  is  not  considered.  ^  But  still,  there 
is  no  harm  in  admitting  impredicative  polymorphism  in  an  explicitly  typed  intermediate 
language  as  long  as  type  checking  remains  decidable. 

The  rule  [□",*"]  forces  the  body  of  a  type  abstraction  to  have  a  value  type.  Thus 
the  MTS  specification  enforces  in  a  natural  way  the  restriction  to  value  polymorphism 
present  in  SML’97  (this  restriction  ensures  type  soundness  in  the  presence  of  side  effects, 
see  e.g.,  [22,23,49]). 

In  summary,  here  are  the  rules  we  consider. 

The  source  language  for  the  encoding  in  the  MTS  given  by  IZml  is  the  fragment  of 
SML’97  given  in  Fig.  3.  A  minor  difference  to  SML’97  is  the  syntactic  distinction  between 
variables  /  bound  by  fix  f.e  and  other  variables  x.  Both  are  considered  values,  but  the 
translation  treats  them  differently.  Furthermore,  SML’s  letrec  rc  =  u  in  e  is  syntactic 
sugar  for  let  x  <=  fix  f.v{x  :=  /}  in  e.  We  have  chosen  the  syntax  with  fix  to  simplify  the 
translation. 

The  intended  operational  semantics  is  call-by-value,  which  we  formalize  by  defining 

*  Actually,  Pure  Type  Systems  with  Universe  Inclusion  have  been  studied  and  formalized  in  [41]  and  it 
would  make  sense  to  use  them  as  a  basis. 
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E  ::=  [  ]  I  E@e  \  v@E  |  ifO  £'  e  e  |  succ  E  \  pred  E 


{Xx.e)@v 

1-^ 

e{x 

u} 

(fix  f.e)®v 

e{f 

fix  /.6}@V 

\et  X  =  v  \r\  e 

e{x 

w} 

ifO  0  ei  62 

ei 

ifO  {i  +  1)  Cl  62 

62 

succ  i 

(*  + 

1) 

pred  (i  +  1) 

i 

pred  0 

1 — y 

0 

li-^r 

EW 

E[rl 

Fig.  4.  Evaluation  Relation  for  SML’97  Fragment 


a  small-step  evaluation  relation  using  the  evaluation  contexts  E  and  reduction  rules 
shown  in  Fig.  4.  The  reduction  for  fix  f.e  is  slightly  unusual,  but  it  nicely  captures  a 
call-by-value  fixpoint  computation.  Figure  5  recalls  the  typing  rules  of  ML  for  reference. 
We  use  the  notation  r  <  a  if  a  =  Vai . . . VQ:„.r'  and  there  exist  such  that 

T  =  T*{ciii  Ti},  and  gen(r,  r)  =  Vai . . .  Va!„.r  where  {ai, . . . ,  «„}  =  FV(r)  \  FV(r)  with 
FV  denoting  the  set  of  free  variables  in  types  and  type  assumptions. 

The  translation  of  types  and  type  schemes  has  three  layers  (see  Fig.  6).  The  translation 
for  top-level  terms  generates  computation  types.  The  translation  generates  value 
types  and  the  translation  applies  to  type  schemes,  which  also  abstract  over  value 
types.  This  translation  generates  well-formed  types. 

Lemma  1  Let  =  Q-i  o-n  :  where  {ai, . . . ,  «„}  =  FV(cr).  Then 

(i)  Gr  I-  V^[r]  : 

(ii)  G,hC^[rI:*^• 

(in)  h  S^M  : 

The  translation  on  terms  is  structured  after  the  translation  on  types.  It  is  split  into  the 
translations  of  syntactic  values  and  of  non-values.  Since  the  translation  really 
maps  type  derivations  to  type  derivations,  we  assume  access  to  a  syntax-directed  SML 
type  derivation  (as  generated  by  the  typing  rules  in  Fig.  5),  namely  at  variable  accesses 
to  X  :  Vai . . .  Q;„.r  we  assume  access  to  the  instantiation  ai  i->  ri, . . . ,  a„  r„,  and  at 
let  expressions  we  assume  we  know  the  generalized  type  Wax . .  .an-T.  We  indicate  the 
type  information  by  superscripts  and  the  instantiation  by  subscripts.  Figure  7  defines  the 
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r,  a; :  cr  \-sml  x:t  t  <a  r,/:r  \-sml  f  -  t  T  \-sml  i  •  nat 

T,x  :t2  ^sml  e  :  Ti  F  ^sml  Ci  :  T2  t\  F  \-sml  ^2  '•  ^2 
F  I“SML  Aar.e  :  T2  — >  ti  F  h sml  ei@e2  :  ti 

F  ^SML  v:t\  F,  X  :  gen(F,  Ti)  \-sml  e:T2 
F  \-sML  let  X  =  V  in  e  :  T2 
F  I~5ml  Cl  :  nat  F  \-sml  £2  ■  t  F  h sml  ^3  : 

F  \-sML  ifO  Cl  62  63  :  r 
F  \-sML  e  :  nat  F  ^sml  e  :  nat 

F  \-sML  succ  e  :  nat  F  \-sml  pred  e  :  nat 
F,  /  :  T2  ^  Ti  \-SML  e:T2->Ti 
F  hsML  fix  f.e  :  r2  ^  Ti 

Fig.  5.  Typing  Rules  for  SML’97  Fragment 


C"[t) 

=  M  V^[tI 

V^[q:] 

=  a 

V^[natl 

=  nat 

V^|ti  ->  T2] 

=  V^[Til^C^[r2l 

=  V^Ir] 

Fig.  6.  Translation  of  SML’97  Types 
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c^M 

=  unit  V^|u] 

=  let  yi  :  V^|t2  -)•  nl  ^  C^[ei]  in  let  j/2  :  V^|t2I  ^  C^[e2]  in  yi  y2 

Collet  a:'^=Vai...a„.r  ^  g|  ^  :  S^lalC^lej)  (Aoi 

C^fifO  ei  62  eal 

=  let  1/ :  nat  <=  C^[eil  in  ifO  y  C^|e2]  C^lez\ 

C^[succ  e] 

=  let  y  :  int  C^[e]  in  unit  (succ  y) 

C^[pred  e] 

=  let  y  :  int  ^  C^|eJ  in  unit  (pred  y) 

=  m 

=  xV^[ril  ...  V^[t„I 

=  Ay2  :  V^[r2l.let  yi  :  V^It2  ->•  nj  ^  /  in  yi  y2 

V^IAx^'.e] 

=  Aa: :  V^[r].C^[el 

V^Ifix 

=  Ay2  :  V^[r2].let  yi  :  V^[t2  ->  n}  ^  fix  /  :  C^[t2  ri].C*^[e]  in  yi  y2 

Fig.  7.  Translation  of  the  SML’97  Fragment 

translation.  It  generates  well-formed  types  and  is  type-sound.  Let 


—  Vl  •  j  ■  ■  •  iVn  •  ^£r„ 

where  y  ranges  over  all  variables  (fix-bound  and  other  variables,  y  ::=  x  |  /). 

Lemma  2  Let  F  =  {yi  :  ai, . . . ,  :  (J„}.  Let  further  T'  =  {yi  :  A[, ...  ,yn  ■  where 

A[  =  ifyi  is  not  i\x-bound  and  A^  =  otherwise.  Then 

(1)  r  \-sML  e-.T  Gr,  r'  h  C^lej  : 

using  'R-ml- 

Proof  See  Appendix  C.  ■ 

Next,  we  prove  that  the  translation  is  compatible  with  conversion. 

Theorem  5  Suppose  ei  — )•  ca  in  ML.  Then  C^|ei|  =mi  ^^[ea]. 

The  proof  and  some  auxiliary  lemmas  may  be  found  in  Appendix  D. 

Unfortunately,  the  result  cannot  be  strengthened:  it  would  be  more  satisfactory  to  re¬ 
late  to  single-step  MTS  evaluation  (see  Definition  25),  e.g.,  to  have  C^[ei]  i — >rid  C^fca] 
but  that  is  not  possible  due  to  the  translation  of  the  let  and  fix  constructs.  In  addition, 
the  primitives  succ  and  pred  require  a  reduction  step  inside  of  unit  .  The  latter  could  be 
avoided  by  giving  the  primitives  a  computation  type. 

The  MTS  formulation  admits  various  extensions  to  the  SML’97  fragment  either  with¬ 
out  variation  of  the  specification  or  with  only  slight  additions. 
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3.2.1  References 

We  extend  the  syntax  of  our  ML  fragment  by  types  and  terms  related  to  references  and 
the  operations  thereof  in  the  usual  way. 

r  1  ref  r  I  0 

n  .  I  ref  e  I  !  e  I  e  :=  e 

That  is,  there  are  a  new  type  constructor  ref  and  non-value  terms  for  creating  a  reference 
ref  e,  reading  a  reference  !  e,  and  updating  the  contents  of  a  reference  e  :=  e.  The  new 
type  constant  ()  corresponds  to  the  one-element  type  unit  of  ML.  The  typing  rules  are  just 
the  standard  ML  rules  and  are  therefore  omitted.  The  semantics  of  the  operators  can  be 
defined  using  the  monad  of  state  transformers.  However,  we  give  a  standard  operational 
(small-step)  semantics  which  maps  a  state  a  and  an  expression  to  the  next  state  and  the 
reduced  expression.  Let  L  be  a  denumerable  set  of  locations  with  I  €  L  and  let  V  be  the 
set  of  syntactic  values  v. 


E 

ref  E\  \  E\E  :=  e\v:=  E 

V 

::=  ...  1  1  1  0  locations,  unit  value 

a 

e  L^V 

a,  E[ref  u] 

a[l  u],  E[l]  1  0  dom(<7) 

a,E[\  /] 

->■  a,E[a{l)] 

(T,  : —  u]  — y  g\1  i—f  u],.E[()] 

The  remaining  reductions  do  not  affect  the  store  and  are  simple  variations  of  the  ones 
defined  in  Fig.  4. 

To  construct  the  translation  we  need  to  add  three  new  constants  to  the  metalanguage. 
These  constants  are  the  metalanguage’s  operators  to  perform  the  operations  on  references. 
Their  types  are  given  as  follows. 

ref^  :  (Ha: ;  ♦’’.a:  M  (ref  a)) 

\j^  :  (Ha  :  *’'.ref  a  ->  M  a) 

:=j^  :  (Ho: :  *’'.ref  a  a  — M  ()) 

The  typing  makes  it  clear  that  only  values  can  be  stored  in  references.  The  translation 
on  types  extends  as  follows: 


V^|ref  r]  =  ref  V^|t] 

V"|()]  =  0 
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The  translation  on  terms  extends  correspondingly. 

C^Iref  ea^rj  =  let  y  :  V^|r]  ^  C^|e]  in  (ref^  V^M)  y 

C^l\  ea^r]  =  let  y  :  V^|ref  r]  C^|e|  in  {1^  V^Ir])  y 

C^[ei  :=  e2aH+rl  =  let  yi  :  V^|ref  rl  4=  C^|ei]  in 

let  y2  :  C^[r]  <^=  C^|e2]  in  (  :=j^f  V^[t])  yiy2 

The  appendix  A  shows  an  example  of  a  sound  compile  time  transformation  with  ref¬ 
erences  and  types. 

Lemma  3  Lemma  1  extends  to  the  new  type  constructors. 

Lemma  4  Lemma  2  extends  to  the  new  constructs. 

Proof  See  Appendix  E.  ■ 

3.2.2  Higher-order  Polymorphism 

Semi-explicit  Polymorphism 

Recently,  there  have  been  several  proposals  to  extend  ML  with  higher-order  polymor¬ 
phism  [17,37].  The  idea  is  that  type  abstractions  are  no  longer  restricted  to  the  top  level 
—  they  may  appear  everywhere  in  types  —  and  in  the  type  (Ha  :  *".q:)  :  the  variable 
a  may  range  over  all  terms  M  :  (impredicative  polymorphism). 

Garrigue  and  Remy  [17]  have  proposed  such  an  extension  of  ML  with  explicit  type 
annotations,  called  semi-explicit  polymorphism.  They  extend  the  term  and  type  language 
by 

u  ;:=...  I  [u  :  cr] 
e  ::=...  I  (e> 
r  ::=...  I  [a] 

The  notation  [cr]  wraps  a  type  scheme  into  a  monotype  which  can  instantiate  type  vari¬ 
ables  and  which  can  occur  nested  within  function  types  ® .  The  basic  idea  is  that  [u  :  a] 
generalizes  the  inferred  type  of  u  to  a  and  wraps  the  type  into  a  monotype  so  that  [u  :  a] 
has  type  [cr].  The  expression  {v)  unwraps  such  a  canned  type  scheme:  if  v  :  [cr]  then 
(v)  :  a.  Roughly,  the  [u  :  a]  expression  corresponds  to  type  abstraction  and  the  (v)  ex¬ 
pression  corresponds  to  type  application,  but  without  giving  the  instantiation  explicitly. 
The  restriction  to  polymorphic  values  is  inherited  from  SML’97. 

The  translation  of  this  extended  language  into  our  instance  of  MTS  is  straightforward. 

v“(Hl 

v^l  [u’’  :  Vq;i  . . .  an.r]  ]  =  Aai  :  .  q;„  : 

=  let  y  :  S^M  <=  C^le]  in  unit  (y  V^lnj  . . .  V^[r„l) 

^  This  glosses  over  the  main  technical  point  of  their  work,  which  makes  type  inference  decidable  for  their 
system.  We  can  safely  ignore  it  here  because  we  start  from  a  given  type  derivation  in  their  system. 
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For  this  translation,  we  can  show  again  that  typing  is  preserved  with  respect  to  the  syntax 
directed  system  given  in  the  type  inference  algorithm  of  Garrigue  and  Remy  [17]. 

Second  order  polymorphic  lambda  calculus 

In  the  same  way,  we  can  encode  an  ML-style  variant  of  the  second  order  polymorphic 
lambda  calculus  F2  where  SML’97  types  and  expressions  (Fig.  3)  are  extended  by  type 
abstraction  and  type  application: 

cr  ::=  a  I  nat  \  a  a  \  Va.cr 

V  Aa.v 

e  Aa.v  \  e{a} 

with  the  standard  typing  rules  and  the  additional  ML-style  call-by-value  reduction  rule 

(AQ!.i;){cr}  1-^  w{q:  :=  a} 

The  translation  of  terms  is  extended  in  essentially  the  same  way  as  for  semi-explicit 
polymorphism. 

V^IAa.u] 

^M|gVa.<7i{^2}]  =  let  y  :  V^^lVa.ai]  C^|e]  in  unit  (y  V^|a]) 
with  the  translation  of  value  types  changed  to: 

V^la]  =  a 

V-^[nat]  =  nat 

V^[cri  — >  a2]  =  V^[<7iJ  — )•  C^[(72j 

V^lVa.a]  =  na:*".V^[(7l 

S.S.S  Polymorphism  by  name 

Leroy  [33]  has  shown  that  the  unsoundness  of  the  naive  approach  to  polymorphic  ref¬ 
erences  in  ML  can  be  attributed  to  the  fact  that  type  generalization  evaluates  its  body 
once  and  for  all.  The  restriction  to  syntactic  values  (as  enforced  by  our  ML  rule  [□’',*”]) 
forces  this  evaluation  step  to  be  a  trivial  step.  Another  sound  option,  that  Leroy  [33]  calls 
polymorphism  by  name,  is  to  equip  type  generalization  with  a  non-strict  semantics  and 
to  repeat  the  computation  whenever  the  corresponding  type  abstraction  is  applied.  This 
corresponds  to  replacing  by  in  the  rules  for  type  abstractions. 

Kpfa  =  {[•'. »‘!.  [»'.  *‘1.  P”.  *‘l.  1°' .  *’)> 

Let’s  go  briefly  over  the  uses  of  the  four  kinds  of  abstractions  (cf.  Fig.  8): 

•  [*'’,  *'’]  image  of  a  source  abstraction; 

•  [D^,  ♦‘’]  image  of  let:  typing  the  innermost  abstraction  around  the  image  of  the  header 
ei; 

•  [D^,  ♦"]  image  of  let:  typing  the  subsequent  abstractions  around  the  image  of  the  header 
ei; 
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•  image  of  let:  typing  the  abstraction  around  the  image  of  the  body  62  in  case  the 

header  is  polymorphic. 

The  modification  of  the  translation  and  the  proof  of  the  preservation  of  typing  are  straight¬ 
forward.  Here  is  the  translation  on  types: 

=  M  V^lrj 

V^[a]  =  a 

V^|nat]  =  nat 

V^[Ti-4T2l=C^lTil-^Cqr2l 

S^r}  =  C^rj 

5^[Va.al  =Ua:*\S^la] 

For  the  translation  of  terms  we  need  to  observe  the  subtle  change  that  variables  (regardless 
whether  fix-bound  or  not)  will  not  be  regarded  as  values,  anymore.  The  encoding  of  call- 
by- value  application  employs  the  method  mentioned  in  Sec.  3.1.  The  value  restriction  is 
no  longer  required.  The  revised  source  language  is  thus 

terms  e  v  \  n 

values  V  ::=  i  |  Xx.e  \  fix  x.e 

non-values  n  ::=  x  \  e@e  |  let  a:  =  e  in  e  |  ifO  e  e  e  |  succ  e  |  pred  e 

Evaluation  is  now  defined  by: 

Epbn  "=  [  ]  I  Epbn®e  I  v®Epbn  \  ifO  Epbr,  e  e  \  succ  Epi^^  \  pred  Epbn 

let  a;  =  ei  in  62  e2{a:  :=  ci} 


with  the  remaining  reductions  as  in  the  SML’97  fragment  (see  Fig.  4) .  Figure  8  defines  the 
translation.  Again,  the  translation  preserves  typing  (we  omit  the  statement  of  a  lemma 
analogous  to  Lemma  1). 


Lemma  5  Let  PEN  be  the  syntax-directed  ML  type  system  with  polymorphism  by  name 
defined  by  Leroy  [33,  Fig.  4,  p-226]. 

r  6  :  T  I“7^p6n 


3.2.4  Call-by-name  ML 

As  an  example  of  a  call-by-name  language,  we  investigate  a  call-by-name  variant  of  ML. 
In  this  variant,  also  non-functional  fixpoints  make  sense  (at  least,  in  an  extended  language 
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C^vj 

=  unit  V^[v] 

=  X  ...  V^[r„] 

=  let  yi  :  V^|t2  n]  ^  C^le\\  in  let  y2  :  V^[t21  ^  C^Ie2]  in  yi  (unit  y2, 

C^[let  =  e[  in  62!  -  (Ax  :  S^la}.C^le2})  (Aoi  =t=".C^[eil) 

C^lifO  ei  62  63] 

=  let  y  :  nat  ^  C^le\\  in  ifO  y  C^[e2l  C^Ies] 

C^|succ  e| 

=  let  y  :  nat  4=  C^feJ  in  unit  (succ  y) 

C^fpred  e| 

=  let  y  :  nat  ^  C^\e\  in  unit  (pred  y) 

=  i 

V^[Ax'^.e| 

=  Ax  :  C^[T].C^[e] 

V^[fix  .e] 

=  Ay2  :  C^[T2].let  yi  :  V^|t2  ->•  TiJ  ^  fix  x  :  C^\t2  -)•  ri|.C^Ie]  in  yi  y2 

Fig.  8.  Translation  for  Polymorphism  by  Name 

with  sum  types)  so  fix  x.e  is  no  longer  a  value,  but  it  is  a  redex  by  itself, 
terms  e  ::=  v  \  n 

values  V  ::=  i  \  Xx.e 

non-values  n  ::=  x  \  fix  x.e  |  e@e  |  let  x  =  e  in  e  |  ifO  e  e  e  |  succ  e  |  pred  e 
Evaluation  changes  in  the  expected  way. 

Ecbn  "=  [  ]  I  Ecbn®e  I  ifO  Eclm  e  e  \  succ  Ean  \  pred  Edm 


(Aa;.e2)@ei  e^ix  :=  Ci} 

let  a:  =  Cl  in  62  e2{a;  ;=  Ci} 

fix  x.e  e{x  :=  fix  x.e} 

I  I— >  r  .Ec6n[^]  ^cbn 

It  turns  out  that  we  can  use  the  same  rule  set  as  for  polymorphism  by  name: 

nd>n  =  =  {[*^  *1,  [*^  *1,  [□^  *1,  [□^  *1} 

The  translation  of  type  schemes  is  identical,  too. 

C^Irl  =  enr} 

V^Irl  = 

=  S^M 
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=  unit 

II 

C-^lfix  x'^.e] 

=  fix  X  :  C^|r].C^[e] 

C^|eP^^i@e2l 

=  let  yi  :  V^[t2  -)■  nj  C^[ei]  in  yi  €^{62] 

C^pet 

=  el  in  62!  =  (Ax  :  <S^|(7l-C^|e2])  (Aai  *’'.C^[ei|) 

C^pfO  ei  62  esi 

=  let  y  :  nat  4=  C^[ei]  in  ifO  y  C^[e2l  C^lez\ 

C^[succ  e| 

=  let  y  :  nat  C-^leJ  in  unit  (succ  y) 

C^[pred  e] 

=  let  y  :  nat  4=  C^[e|  in  unit  (pred  y) 

v^q 

=  i 

V^lAx'^.e] 

=  Ax  :  C^[r].C^[el 

Fig.  9.  Translation  for  call-by-name  ML 

The  translation  of  terms  may  be  found  in  Fig.  9.  In  fact,  it  is  identical  to  the  translation 
in  Fig.  8,  up  to  the  cases  for  fix  x.e  and  e@e. 

We  can  prove  the  following  statements  about  the  translation. 

Lemma  6  LetT  =  {xi  :  ai, . . .  ,Xn  '•  On}  and  F'  =  {xi  :  . . . , x„  :  5^|cr„]}.  Then 

(2)  r  \-sML  e  :  r  ^  Gr,  F'  h  C^lej  : 

usiny  • 

Theorem  6  Suppose  ei  — J-cftn  62-  Then  C^[ei]  =Tni  ^^[62]. 

The  proofs  are  omitted,  because  they  are  very  similar  to  the  ones  presented  for  the  call- 
by-value  variant.  Again,  we  only  obtain  convertibility  of  the  translated  terms,  which  is 
again  due  to  the  translations  of  let,  fix,  and  the  primitives. 

3.3  Encodings  of 

Finally,  we  give  an  outline  of  call-by-name  and  call-by- value  translations  for  Fa,  [19],  also 
known  as  the  higher-order  lambda  calculus.  Figure  10  defines  the  syntax  of  the  source 
language.  We  omit  the  standard  formation  rules  for  constructor  contexts  A,  term  contexts 
0,  constructors  A  xr  :  constructor  conversion  A  t>  ai  =  <72  :  /c,  and  terms  A;  0  >  e  :  <7. 

3.3.1  Standard  Call-hy-Name  Encoding 

Figure  11  shows  a  call-by-name  encoding  of  F^.  In  order  to  prove  that  this  translation 
preserves  typing,  we  need  the  following  specification: 

F,Fcbn  =  {(□",  □"),  [*",  *%  [□^  *1} 
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kinds  K  ::=  Q,  \  K  K 

constructors  a  ::=  a  \  a  a  \  Va  :  K.a  |  Xa  :  K.a  |  cr{(7} 
terms  e  x  \  Xx  :  cr.e  \  eOe  |  Aa  :  K.e  \  e{a} 

Fig.  10.  Syntax  of 


Translation  of  kinds 

/C[/ci  =>  /C21  =  — >■  !Cln2l 

Call-by-name  translation  of  constructors 
7-|a^^]  =  M  a 

=  a  V[q!] 

T|(Ti  — >  <T2l  =  M  (TIcTi]  T|<T2])  V|(7i  — >  <72! 

nVa  :  K.aj  =  M  (na':^:!^!.  TM)  V|Va  :  K.a] 

T[Aq;  :  K.a}  =  Xa  :  /C|K|.7”[a|  V[Aq:  :  K.a} 

ria,{a2}\  =r[ai|(Vla2l)  V[ai{a2}l 


=  a 


T[ai]  T|a2| 
na:X:[Kl.  r[a| 
Aa  :  /CM.Vlcr] 


Call-by-name  translation  of  terms 

Olx}  =  X 

0\Xx  :  a.e}  =  unit  (Ax  :  T[<T|.C?|e|) 

e>|ef^‘"i@e2|  =  let  y  :  V[a2  ai]  <=  Ofei}  in  y  {0[e2}) 

0\h.a  :  K.e]  =  unit  (Aa  :  /C[K].C>[e]) 

^|gVQ:K.(Ti|^2||  =  let  y  :  V[Vq!  :  K.cri|  C?|e]  in  y  (V[cr|) 

Fig.  11.  Standard  call-by-name  encoding  of 
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Objects 

O  ::=  X  I  unit  W  \  \tt  x  \  W  O  \v\  O  \  x  O  \  x  W  \W  O  \  W  W 
Values 

W  :;=  Ax  :  f.O  \  Xa  :  K.O 
Value  constructors 

W  ::=  a  \f  f  \  Ila:k.f  \  Xa  :  K.W  \  W  W 
Computation  constructors 

f  :;=  \MW\Xa:  K.f  \  f  W 

Kinds 

k  \  k^k 

Fig.  12.  Image  of  the  standard  call-by-name  translation 

Lemma  7  For  a  constructor  context  A  =  oii  :  Ki,  an  Kn  let  Ga  =  cki  ^  •  •  •  ,an  ■ 

/C|Kn].  For  a  term  context  0  =  xi  :  . . . ,  x„  :  an  let  Gq  =  xi  :  T[ai], . . . , Xn  :  T|an]. 

(i)  If  A  >  a  :  K,  then  Ga  I"  V[a]  :  /C|k]. 

(ii)  // A;0  >  e  :  a  then  Ga,Gq  h  0|e]  :  TM. 

Harper  and  Lillibridge  [22,  24]  have  defined  a  standard  call-by-name  semantics  for 
a  superset  of  the  calculus  considered  here.  For  their  small-step  operational  semantics 
—>std-cbn  (see  Appendix  F.l),  we  can  show  that  the  translation  is  compatible  with  single- 
step  reduction  for  MTS  (see  Definition  25). 

Theorem  7  Suppose  A;0  >  ei  :  ai  and  ei  -^std-cbn  ^2  then  0[ei|  i — >mi  C>|e2]. 

In  order  to  characterize  the  connection  between  the  source  calculus  and  the  image 
precisely,  we  work  towards  the  definition  of  an  inverse  translation.  The  first  step  is  the 
characterization  of  the  image  of  the  translation. 

Lemma  8  The  grammar  in  Figure  12  characterizes  the  closure  of  the  image  of  the  stan¬ 
dard  call-by-name  encoding  under  =mi- 

Figure  13  defines  the  inverse  translation. 

Lemma  9  Suppose  F  h  O  :  T.  Then  there  exists  a  constructor  context  A  and  a  term 
context  0  such  that  A;  0  >  :  T“^[T']. 

Theorem  8  Suppose  F  h  Oi  :  T  and  Oi  i — ymi  O2  then  =p  0~^\02\- 

The  reduction  rule  pz  is  the  culprit  for  having  instead  of  =std-cbn  or  even  -^atd-ctm- 
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Objects 

—  X 

0-1  [unit  W] 

=  W-1[W"1 

0-1  [let  x  -.W  ^Oi\x\ 

O2]  =  (Arc  :  V-i[lV].0-i[02l)@C?-i[0il 

0-‘[i  01 

=  ;r@0-i[0] 

0-1  [a;  W\ 

=  a:(9V-i[IV] 

o-^lw  0} 

=  w-i[ivi@o-i[oi 

0-1  [M^  W] 

=  >V-1[IV]@V-1[IV] 

Values 

>V-i[Aa; :  f.O} 

=  Arc  :  r-i[ri.0-i[0] 

>V-i[Aa  :  K.Oj 

=  Aa  : /C-i[K].0-i[0l 

Value  constructors 

V-i[al 

=  a 

v-i[ri  ->  fal 

=  r-i[fii^r-i|f2i 

V-i[na:^.fl 

=  Va  :  /C-i[Kl.r-i[f] 

V-i[Aa:^.lV] 

=  Aa:X:-i[K].V-i[PVl 

V-^lWi  WtI 

=  V-i|IVil@V-i[lV2l 

Computation  constructors 

T-'H 

=  a 

r-i[M  wj 

=  V-1[IV] 

r-i[Ao! :  K.f] 

=  Aa :  /C-i[Kl.r-i[Tl 

r-^lf  Wj 

=  r-i[f]<9v-i[ivi 

Kinds 

/c-i[*i 

=  n 

;c-i[Ki  K2I 

=  /c-i[Ki]=^x:-i[K2] 

Fig.  13.  Inverse  of  the  standard  call-by-name  translation 
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Call-by- value  translation  of  constructors 

— >■  <72!  =  M  T^[<72l)  V^lcTi  ->  (72J  =  V^[<Ti|  — >  T'^[cr2j 

Call-by- value  translation  of  terms 
0^\x\  =  unit  a: 

O^lXx  :  a.e]  =  unit  (Ax  :  V^[cr].C>^|e|) 

0V|g^2-><Ti@gj  ^  let  .  yV|^2  <Ti]  ^  e>'^[ei]  in  let  ^2  :  <^2  4=  C>^[e2l  in  yi  y2 
Fig.  14.  Standard  call-by-value  encoding  of 


3.3.2  Standard  Call-by-Value  Encoding 

Next,  we  consider  a  call-by-value  translation.  The  changes  with  respect  to  the  call-by¬ 
name  version  are  minimal:  the  translation  of  the  function  constructor  changes  because 
call-by-value  functions  take  values  as  arguments.  This  causes  a  reclassification  of  x  as  a 
value  and  changes  in  the  translations  of  (value)  abstraction  and  application.  Figure  14 
gives  those  parts  that  have  changed  with  respect  to  Fig.  11.  The  MTS  specification  for  the 
image  of  the  call-by- value  translation  changes  only  the  rule  for  value  abstractions  (with 
respect  to  the  call-by-name  specification  TZFcbn)- 

npclr.  =  {(□",  □"),  K,  *1,  *1} 

Again,  we  can  prove  our  two  standard  results. 

Lemma  10  For  a  constructor  context  A  =  ai  :  Ki,  ...,  ocn  :  Kn  let  Ga  —  ,  o^n  • 

For  a  term  context  0  =  Xi  :  ai, . . . , x^  :  cr„  let  G@  =  Xi  :  V'^[cri], . . . ,  Xn  :  V^[cr„]. 

(i)  If  A  >  a  :  K  then  Ga  b  V'^lcr]  :  /C[/c]. 

(ii)  If  A-,Q  >  e  :  a  then  Ga^Gq  >  O^lej  :  T^|cr]. 

Theorem  9  Suppose  A;0  >  ei  :  ai  and  ei  -^std-cbv  ^2  then  1 — >rni  • 

See  Appendix  F.2  for  the  definition  of  -^std-cbv- 

3.3.3  ML-style  Call-by-Value  Encoding 

It  is  also  possible  to  consider  an  ML-style  variant  of  the  call-by-value  semantics.  The 
difference  to  the  standard  call-by-value  semantics  lies  in  the  fact  that  ML  performs  com¬ 
putations  under  type  abstraction.  The  ML-style  translation  presents  only  a  few  changes 
with  respect  to  the  standard  call-by-value  encoding  in  Fig.  14.  Therefore,  Figure  15 
presents  only  the  changes,  which  amount  to  the  cases  involving  the  constructor  Va  :  K.a . 

We  can  prove  our  two  standard  results. 

Lemma  11  For  a  constructor  context  A  =  ai  :  ki,  . . . ,  an  ’  Hn  let  Ga  —  Q^i  •  . . .  ,an  ■ 

/C[/Cnl-  For  a  term  context  0  =  xi  :  (7i,...,x„  :  <7„  let  Gq  =  xi  :  V^^[(Ti],  . . .  ,x„  : 

v^^Ki. 
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ML-style  call-by- value  translation  of  constructors 

r^^[Va  :  K.a]  =  V^^[Va  :  K.a]  =  Ua-XM. 

ML-style  call-by-value  translation  of  terms 

O^^Aa  :  K.e]  =  Xa  : 

^My|gVa:/c.ai{^2}l  =  O^^lej 

Fig.  15.  ML-style  call-by-value  encoding  of  Fa» 


(i)  If  A  >  a  :  K  then  Ga  b  V^^[cr]  :  /C[k1. 

(ii)  // A;0  >  e  :  a  t/*en  Ga,G©  > 

Theorem  10  Suppose  A;0  >  ei  :  (Ti  anrf  ei  -^mi-cbv  ^2  then  0^^[eij  =  ml  0^{e2l 

See  Appendix  F.3  for  the  definition  of  -^mi-cbv 

We  can  strengthen  the  result  if  we  restrict  the  source  language  to  only  admit  value 
polymorphism  as  in 

e  ::=...  I  Aa  :  k.v 

In  this  case,  the  reductions  are  compatible,  again. 

Theorem  11  Suppose  ei  adheres  to  the  value  restriction,  A;  0>ei  :  <Ti,  and  ei  —^mi-cbv  ^2 
then  1 — >jni  G'^^|e2]. 

3.3.4  ML-style  Call-hy-Name  Encoding 

It  is  possible  to  define  a  call-by-name  variant  of  the  ML-style  call-by-value  encoding 
considered  above.  Harper  and  Lillibridge  [24]  show  that  this  semantics  actually  coincides 
with  the  standard  call-by-name  semantics  on  closed  terms  of  base  type.  Therefore,  we  do 
not  consider  it  here  in  any  depth. 

3.3.5  FLINT 

Shao  [45]  has  considered  an  extension  of  Fa,  with  the  ML-style  call-by-value  semantics  as 
an  intermediate  language  for  compilation.  The  main  differences  to  our  system  (Sec.  3.3.3) 
are  the  following. 

(i)  The  term  language  of  FLINT  is  restricted  to  A-normal  form.  In  A-normal  form,  the 
results  of  all  non-trivial  computatations  have  to  be  named  [16].  Therefore,  FLINT 
restricts  function  application  to  the  form  let  x  =  v@v  in  e  (this  construct  does  not 
generate  polymorphism)  and  relies  on  a  preceding  transformation  to  A-normal  form. 
This  restriction  slightly  simplifies  the  translation  of  applications: 

X  =  in  ej  =  \etx:  <=  (G’^^[u2l)  in 

where  drops  the  leading  unit  •  from  restricted  to  values. 
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(ii)  FLINT  has  several  built-in  primitives.  These  can  be  dealt  with  just  as  demonstrated 
for  succ  and  pred  in  the  ML  encoding  (see  Sec.  3.2). 

(iii)  flint’s  type  system  has  predicative  polymorphism.  It  achieves  this  by  distinguish¬ 
ing  between  constructors  and  types  and  by  having  an  explicit  type  forming  operator 
T  that  maps  a  constructor  of  kind  to  a  type  (as  introduced  by  Harper  and  Mor- 
risett  [26]). 

One  way  to  model  this  would  be  to  extend  the  set  of  sorts  by  a  sort  O  with  O  : 
for  the  constructors  and  add  a  rule  like 

r  \-  A:0 
r  h  T{A)  : 

to  the  MTS  framework.  This  way,  the  specification  would  be 

«],(❖,  0,0)} 

which  is  well-behaved  in  the  current  framework. 

(iv)  There  is  a  new  kind  of  sequence  kinds  k®  k  in  FLINT  (to  express  the  type  of  a 
module)  which  is  not  present  in  MTS,  but  could  be  added  without  much  difficulty. 

4  Properties  of  Monadic  Type  Systems 

The  meta-theory  of  Monadic  Type  Systems  is  complicated  by  two  major  hurdles,  namely 
the  non-termination  of  ^reduction  and  the  non-confluence  of  //-reduction.  Nevertheless, 
MTSs  enjoy  some  important  properties  such  as  Subject  Reduction  and  Classification  for 
injective  specifications.  Besides,  a  large  class  of  MTSs  is  strongly  normalizing  w.r.t.  fitfj,- 
reduction  and  has  decidable  type-checking. 

4-1  Basic  properties 

Basic  properties  such  as  the  Substitution  Lemma  or  the  Generation  Lemma,  which  do 
not  rely  on  confluence  nor  normalization,  are  proved  in  exactly  the  same  way  as  for  Pure 
Type  Systems. 

The  first  Lemma  states  that  judgements  are  closed  under  substitution — substitution 
is  extended  to  pseudo-contexts  in  the  obvious  way. 

Lemma  12  (Substitution)  Assume  F,  x  :  4,  A  h  B  :  C  and  V  h  a  :  A.  Then  also 
r,  A{a:  :=  a}  h  B{x  :=  a}  :  C{x  a}. 

Proof  By  induction  on  the  derivation  of  F,  x  :  A,  A  h  B  :  (7.  ■ 

The  second  Lemma  states  that  introducing  new  assumptions  do  not  aflPect  derivability — ^we 
write  A  D  F  if  (x  :  4)  €  A  whenever  (x  :  ^4)  G  F. 

Lemma  13  (Thinning)  IfV  h  A:  B  and  A  3  F  is  legal  then  A  h  A  :  B. 

Proof  By  induction  on  the  derivation  of  F  h  A  :  J5.  ■ 

Conversely,  one  can  remove  unused  assumptions  without  affecting  derivability.  However, 
this  result  is  surprinsingly  diflficult  to  prove  and  is  postponed  until  the  end  of  this  Section. 
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r  I-  srC 
r  h 


3(s,  S  )  C  1^.  C  — ml  S 

=>■  3s  G  <S,  jD  €  7”.  C  =mi  D  A  {x  :  D)  €  F 
A  ri-£>:s  A  xeV^ 

r  f~  At:  a.  b  C  3s  G  «S,  jB  G  7”.  C  =mi  n^c:  A.  B  A  T,x  A  b  i  B 

A  r  h  na;:j4.  B  :  s 

r  h  Bx-.A.  B  :C  =>  3(si,  S2,  ss)  C  =mi  Ss  A  F  h  A  :  Si 

A  V,x  :  A  \-  B  :  S2 

T  \-  Fa:C  =>  3x  G  V,  A,  5  G  T.  C  :=  a} 

A  F  h  F  :Ilx:A.B  A  F  h  a :  A 

V  \-  i\x  x'.A.b :  C  ^  3B  G  T.C  =mi  A  A  >1  =  M£  A  F,a;:^l-6: 

T  ^  \Qlx-.A^MmN  .C  ^  ^B  eT.C  =rrd^  B  A  F,a; :  A  h  iV  :  M  B 

A  T  h  M:MA 

F  h  unit  M  :  C  =>  3B  eT.  C  =mi  MB  A  F  h  M  :  B 

A  F  h  M  B  : 

F  h  M  A  :  C  ^  C=mi*‘'  /\  ^se  *’'}.  F  h  :  s 

F  h  nat :  C  C  =mi 

F  h  [n]  :  C  C  =mi  nat 

F  h  succ  M  :  C  =>  C  =mi  nat  A  F  h  M  :  nat 

F  h  pred  M  :  C  =»  C  =,„j  nat  A  F  h  M  :  nat 

F  h  ifO  M  Ml  Ma  :  C  3B  G  T.  C  M  B  A  F  h  M  :  nat 

A  FI-Mi:B  A  FhMarB 

Fig.  16.  Generation 

The  next  Lemma  provides  an  analysis  of  the  possible  derivations  of  a  judgement.  The 
lemma  is  used  extensively  throughout  the  paper. 

Lemma  14  (Generation)  See  Figure  16. 

Proof  By  induction  on  the  structure  of  derivations  using  the  Thinning  Lemma.  ■ 

The  last  result  states  that  types  are  correct,  in  the  sense  that  if  A  :  B  then  either  B 
is  a  sort  or  B  :  s  for  some  sort  s. 
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Lemma  15  (Correctness  of  types)  IfT  h  A:  B  then  either  B  E  S  or3s£S.r  h 
B  :  s. 


Proof  By  induction  on  F  h  A:  B. 


4.2  Strong  normalization 

Fixpoint  reduction,  i.e.  ^reduction  is  not  normalizing  hence  we  cannot  expect  a  MTS  to 
be  mi-strongly  normalizing.  However  MTSs  may  still  be  /3i;u-strongly  normalizing.  The 
purpose  of  this  Subsection  is  to  define  such  a  class  of  MTSs.  The  actual  definition  of  the 
class  is  determined  by  the  technique  used  to  prove  strong  normalisation  rather  than  by 
any  intrinsic  criterion.  If  we  view  MTS-specifications  as  a  subclass  of  PTS-specifications, 
this  class  corresponds  to  those  specifications  which  may  be  embedded  in  Barendregt’s 
A-cube  [3,4]. 


Definition  12  Let  S  =  («5,  be  a  MTS-specification. 

(i)  The  set  of  top-sorts  is  defined  as  {s  G  <S  |  Vs'  G  S.  (s,  s')  ^  A}. 

(ii)  The  set  S-^  of  bottom-sorts  is  defined  as  {s  G  «S  |  Vs'  G  S.  (s,'  s)  ^  A}. 

(iii)  S  is  cubic  if 

(a)  S  =  S^[J  5-L, 

(b) 

(c)  for  every  (si,  S2,  S3)  G  7?.,  S2  G  5-‘-  S3  G  S-^. 


Our  method  to  prove  strong  normalization  is  to  define  a  reduction-preserving  transla¬ 
tion  from  cubic  MTSs  to  the  Calculus  of  Constructions  with  Fixpoints  ACax  [1,5]-  The 
translation  could  be  generalized  to  specifications  that  do  not  comply  with  requirement 
(a)  of  the  above  definition;  in  that  case  the  target  language  would  be  a  Logical  Pure  Type 
System  with  Fixpoints  at  the  *  level.  However,  we  would  need  to  prove  such  systems  to 
be  strongly  normalizing  in  order  to  conclude — a  method  is  suggested  in  [5]  but  is  still  in 
need  to  be  carried  out  in  detail.  Following  standard  practice,  we  write  AS  \=  SN(/3i^)  iff 
every  legal  term  in  AS  is  /3t/r-strongly  normalizing. 


Theorem  13  If  S  is  a  cubic  specification,  then  AS  |= 


Proof  For  the  sake  of  simplicity,  we  consider  a  slightly  modified  syntax  where  ifO  ex¬ 
pressions  are  labelled  by  their  result  types,  i.e.  are  of  the  form  ifO^  M  Mi  M2.  This 
enables  us  to  encode  ifO  impredicatively.  For  the  same  reason,  we  only  consider  the  rule 
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pred  (succ  M)  M  for  M  a  numeral.  The  translation  [.]  defined  inductively  as  follows: 


[a:]  =  X 
\s]=s 

[Aa: :  A.t\  =  Aa; : 

\Ux:A.B]  =  nx:  lAllB] 

\tu]  -  \t]  M 

[let  x:A  4=  N  m  Ml  =  (Ac:  [A].  \M])  [A?'] 

[unit  =  \t\ 
fM  41  =  Ml 

[fix  ox  A.  M]  =  fix  x:  [^].  [M] 

[nat]  =  Ha:  *.  a  — >  (a  — >■  a)  — >■  a 

[[nil  =  n 

[succ  Ml  =  Aa::*.  Ac:q;.  Xf:a  — >  a.  /  ([Ml  a  x  f) 

[pred  Ml  =  pred  [Ml 

[ifO^  M  Ml  M2I  =  [Ml  [^1  [Mil  (A-  [^1-  [M2I) 

where  n  and  pred  are  the  impredicative  encodings  of  n  and  predecessor  respectively.  [20, 
page  90].  The  translation  [.1  preserves  conversion  and  maps  legal  terms  of  AS  to  le¬ 
gal  terms  of  ACfix-  In  addition  [.1  maps  infinite  /?/ut-reduction  sequences  with  infinitely 
many  ^^/i-steps  to  infinite  j5;0'-reduction  sequences,  where  /^'-reduction  is  defined  by  the 
contraction  rule: 

P  {{>x:A.  Q)  R)  {kc-.A.  P  Q)  R  provided  x  ^  FV(P) 

Conclude  by  proving  that  SN(y5,5')  =  SN(/?),  see  Appendix,  and  by  noting  that  an  infinite 
;0//t-reduction  sequence  must  contain  infinitely  many  ;5//-steps.  ■ 

4.3  Confluence 

/^-reduction  is  not  confluent  on  pseudo-terms,  as  illustrated  by  the  following  example:  ® 

let  x:A<=  M  in  X  =n  let  x:A<^  (let  ^  M  in  (unit  y))  in  x 
=fi  let  y:B  <=  M  in  (let  x:A^  (unit  y)  in  x) 
let  x\B  ^  M  in  X 

®  However,  we  believe  that  the  failure  of  confluence  for  monadic  reduction  is  a  consequence  of  the  choice 
of  primitives  rather  than  of  the  intrinsic  nature  of  monadic  languages  and  that  alternative  formulations 
of  the  monadic  syntax  would  not  suffer  from  non-confluence. 
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The  failure  of  confluence  for  m/-reduction  requires  a  careful  elaboration  of  the  meta- 
theoretical  results.  The  solution  adopted  in  this  paper  is  to  ‘complete’  ml-reduction.  Put 
it  otherwise,  we  consider  an  extension  of  mZ-reduction  that  is  confluent  and  that  has 
the  same  reflexive-symmetric-transitive  closure  as  mZ-reduction.  An  alternative  would  be 
to  follow  [18]  and  define  a  notion  of  erased  pseudo-term  and  of  erased  reduction,  but  our 
approach  has  the  advantage  of  being  more  concise. 


Definition  14  The  notion  of  K-reduction  is  defined  by  the  contraction  rules 

let  x:A<=  M  \t\  N  let  x:*  <=  M  \n  N 
The  notion  of  mZ-t-reduction  is  defined  as  the  union  of  ml  and  k. 

The  notions  of  reduction  ml  and  mZ-l-  yield  the  same  convertibility  relation. 


Lemma  16  M  =mi+  N  M  =rrd  N 

Proof  Only  the  direct  implication  is  interesting.  To  prove  it,  first  show  by  induction  on 
the  structure  of  M  that  M  N  implies  M  =.„a  N.  Then  proceed  by  induction  on  the 
derivation  of  M  =mi+  A^-  * 

Next  we  prove  that  ml+  is  confluent.  We  start  with  some  preliminary  results. 


Theorem  15  SN(/i)  =  T. 

Proof  Using  Finiteness  of  Developments.  More  precisely,  define  the  set  U  of  underlined 
X-terms  by  the  abstract  syntax: 

W  =  V|  •  \UU\XVM\{XV.U)U 

Then  define  the  notion  /3  of  underlined  ^-reduction  by  the  contraction  rule 

{Xx.  M)  N  -^0  M{x  :=  N} 
and  the  notion  of  reduction  ^  by  the  contraction  rule 

P  ((Ao;.  Q)  R)  (Aa:.  P  Q)  R 

provided  x  ^  FV(P).  One  possible  formulation  of  Finiteness  of  Developments  states 
U  =  SN(^).  Using  an  analysis  of  the  possible  infinite  ^'-reduction  sequences,  one  can 
prove  U  =  SN(j5/3'),  see  Appendix.  To  prove  our  theorem,  define  a  translation  [.]  :  T  W 
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as  follows: 

[x]  =  X  X  eV 

[s]  =  •  seS 


[Ar:  A.  t] 

=  K  (Ax.  [t])  [A] 

[Ux-.A.B] 

=  (Ax.  [B])  [^] 

[tu] 

=  •  W  [«] 

[let  x:A^  N  in 

M]  =  (Ax.  K  [M]  [A])  [A^] 

[unit  t] 

=  W 

[M  A] 

=  [^] 

[fix  x:  A.  M] 

=  K  (Ax.  [M])  [A] 

[nat] 

=  • 

[M] 

“  • 

[succ  M] 

=  [M] 

[pred  M] 

=  [M] 

[ifO  M  Ml  M2] 

=  •  [M]  [Ml]  [M2] 

To  conclude,  we  only  need  to  show  that  [.]  maps  infinite  sequences  of  /if-reductions  are 
mapped  into  infinite  sequences  of  ^'-reductions,  i.e.  for  every  P,  Q  G  T, 

P-^^Q  =^>  [Q] 

The  latter  is  proved  by  induction  on  M  G  T.  We  treat  three  cases: 

•  P  =  let  -T=  (unit  N)  in  M  and  Q  =  M{x  :=  iV}. 

[P)  =  (ire.  K  [Mj  [4)  [JV] 

^j(irr.  M)  [itf] 

-»s(M]{rc  :=  [JV|} 

=  [M{x  :=  N}] 

^  [Q] 

•  P  =  \et  x:A4=  M  in  (unit  x)  and  Q  =  M. 

[P]  =  (Aa;.  K  [a:]  [A])  [M] 

-^0{Xx.  [a:])  [M] 

=  [Q] 

•  P  =  let  X2:A2  ^  (let  a;i:^i  <=  Mi  in  M2)  in  M3  and  Q  =  let  a:i:  Ai  <=  Mi  in  (let  X2: 
A2  <=  M2  in  M3)  assuming  a;i  ^  FV(M3)  U  FV(A2).  We  have 

[P]  =  (Aa;2.  K  [M3]  [^2])  ((A:ra.  K  [M2]  [Ai])  [Mi]) 


33 


— (A^i-  (A^2-  K  [A/3]  [^2])  (K  [^2]  [-^1]))  [-^i] 

(A^i-  K  ((A3^2-  K  [M3]  [^42])  [M2])  [Ai])[Mi] 

=  (Aa^i-  K  [let  2:2:  ^2  ^  M2  in  M3]  [Ai])  [Mi] 

=  [let  Xi:^!  ^  Ml  in  (let  rc2:i42  ^  M2  in  M3)] 

^  [Q] 

Other  cases  follow  directly  from  the  induction  hypothesis.  ■ 

Proposition  16  nK-reduction  is  confluent. 

Proof  jUK-reduction  is  locally  confluent,  hence  by  Newman’s  Lemma  it  is  enough  to  show 
that  SN(//k)  =  T.  This  may  be  proved  by  noting  that: 

(i)  [.]  maps  K-redexes  to  /c'-redexes  where  k'  is  the  reduction  rule 

M  — •  if  M  ^  • 

(ii)  /c'  may  be  postponed  and  is  strongly  normalising. 


Theorem  17  (Confluence)  ml+  is  confluent. 

Theorem  17  is  useful  in  proving  several  subsequent  results,  especially  Subject  Reduction. 
However,  there  does  not  seem  to  be  any  direct  method  from  which  to  derive  confluence 
of  m/-reduction  on  legal  terms,  even  if  we  assume  the  specification  to  be  cubic.  The 
situation  is  to  be  contrasted  with  that  of  PTSs  with  /??7-conversion  [18],  where  confluence 
of  /?77-reduction  on  legal  terms  is  derived  from  normalisation  and  confluence.  In  our  case 
we  do  not  have  m/-normalization  so  we  cannot  conclude. 

4.4  Subject  Reduction 

Subject  Reduction  is  a  fundamental  property  of  type  systems:  from  a  practical  point  of 
view,  it  ensures  that  types  are  closed  under  reduction.  From  a  theoretical  point  of  view, 
it  is  used  throughout  the  metatheory  of  type  systems,  e.g.  in  consistency  proofs  and 
in  operational  semantics.  As  expected,  the  failure  of  confluence  for  ml-reduction  yields 
slight  complications  in  the  proof  of  Subject  Reduction.  Nevertheless  the  proof  of  Subject 
Reduction  for  A^-reduction  proceeds  as  usual. 

Theorem  18  (t^-subject  reduction)  T  \-  A -.  B,  A  A'  =»  T  A' :  B 
Proof  Prove  by  simultaneous  induction  on  the  derivation  of  P  h  M  :  A: 

•  M  — N  r  1“  N  :  A 

•  if  A  =>  A  h  M  :  R 

(Recall  that  is  extended  to  contexts  by  the  clause  A  B  P,  a; :  A,  A 

T,x:B,A.)  ■ 

The  proof  of  Subject  Reduction  for  y^/i-reduction  requires  a  preliminary  result,  known  as 
the  Key  Lemma,  which  follows  directly  from  Theorem  17. 
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Lemma  17  (Key  Lemma) 

•  IfUxiA.  B  =mi  Xlx'.A! .  B'  then  A  =mi  A'  and  B  B'. 

•  If  M  A  =jni  M  A'  then  A  =mi  A'. 

Proof  The  second  step  of  both  proofs  follows  from  confluence  of  -¥mi+- 

Ilx:  A.  B  =jni  nx:  C.  D  ^  Ha::  A.  B  =mi+  nrc:  C.  D 

A  —fnl+  C  A  B  —ml+ 

A  =ml  Cab  =ml  D 

MA=miMA'  MA=mi+MA' 

A  —ml+  A 
^  A  —ml 


Theorem  19  (;d//-subject  reduction)  r  h  A:  B,  A  A'  r  h  :  B 

Proof  Prove  by  simultaneous  induction  on  the  derivation  of  P  h  M  '.A: 

•  M  N  =>  r\-N:  A 

•  if  r  — ypfj,  A  A  M  :  B 

(Recall  that  is  extended  to  contexts  by  the  clause  A  B  F,  a; :  A 

r,x:B,A.)  ■ 

The  next  result  is  a  mild  strengthening  of  the  Key  Lemma  which  is  useful  in  the  proof  of 
strengthening. 

Lemma  18 

•  If  s  =mi  s'  then  s  =  s'. 

•  If  A  =mi  M  B  and  A  legal  then  A  M  C  for  some  C  =mi  B. 

•  If  A  =mi  s  and  A  legal  then  A  s. 

•  If  A  =m.i  ria::  B.  C  and  A  legal  then  A  -»p  Ha;:  D.  E  with  B  =mi  D  and  C  =mi  B. 

An  important  consequence  of  Subject  Reduction  is  strengthening,  which  is  proved  along 
the  same  lines  as  in  [18]. 

Definition  20  S  preserves  sorts  if 

T  \-  A:s,T  \-  A':s',  A=miA'  s  =  s' 

The  above  technical  assumption  ensures  that  strengthening  holds. 

Theorem  21  IfS  preserves  sorts,  then  S  satisfies  strenghtening,  i.e. 

ri,a;:  A.Fa  h  fe:B,  a;^FV(r2)UFV(6)UFV(B)  =4^  ri,r2h6:B 
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Proof  First  show  that 

Ti,x:A,r2\-b:B,x^  FV(r2)UFV(6)UFV(B)  =J>  SB'  eT.B  =mi  ^'aFi,  Fa  \-h:B'  (*) 

Then  assume 

Fi,x  :  Fa  h  6  :  B  (&),  x  ^  FV(Fa)  U  FV(6)  U  FV(S) 

Hence  there  exists  C  =mi  B  such  that 

Fi,Fa  b:C 

By  Correctness  of  Types  on  (&)  we  find  that  B  €  «S  or  Fi,a:  :  A,  Fa  F  .B  :  s  for  some 
s  eS.  In  the  second  case,  apply  (*)  to  find  E  =mi  s  such  that 

Fi,Fa  h  B:E 


By  Lemma  18  and  Subject  Reduction, 


By  (conversion) 


Fi,Fa  \-  B:s 


Fi,Fa  h  6:B 

In  the  first  case,  apply  the  Lemma  18  to  conclude.  In  both  cases,  we  obtain 

Fi,Fa  \-  b:B 

To  conclude  the  proof,  we  prove  (*)  by  induction  on  the  structure  of  derivations. 
•  Assume  the  last  rule  is 


r,y:C\-N:D  T  \-  {Ux:C.  D)  :  s 
T  \-  )y:C.N  lUy.C.D 

with  F  =  Fi,  X  :  A,  Fa  and  x  0  FV(F2)  U  FV(^:  C.  N)  U  FV(ny:  C.  D).  By  induction 
hypothesis,  there  exists  E,F  in  E  such  that  E  =mi  D  and  F  —mi  s  and  such  that 


Fi,F2,i/:C  h 
Fi,F2  h  ny.C.D-.F 

By  Generation,  there  exists  (si,  sa?  ss)  ^  ^  such  that 

Fi,F2  f-  Gisi 

FijFa,!/  :C  h  D  :  S2 

By  Correctness  of  Types,  there  exists  s'  E  S  such  that 

Fi,F2,y:C  \-  E  :  s' 
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By  Preservation  of  Sorts,  s'  =  S2  and  hence  by  (product) 


ri,r2  H  Uy.C.  D  :  S3 


By  (abstraction), 

•  Assume  the  last  rule  is 


ri,r2  h  >y:C.M  :Uy:C.D 


T  \-  M:MC  T,y:C  h  N:M  D 
r  h  \et  y:C  ^  M  \n  N  :  M  D 

with  r  =  Pi, a; :  A, r2  and  x  ^  FV(r2)  U FV(let  y.C  ^  M  \n  N)U FV{D).  By  induction 
hypothesis,  there  exists  E,F  in  T  such  that  E  =mi  M  C  and  F  =rni  M  D  and  such  that 

ri,r2  \-  M:E 
Ti,r2,y:C  \-  N:F 


By  Correctness  of  types,  ri,r2  h  C  :  s.  By  Extended  Uniqueness  of  Types  s  =mi 
By  Lemma  18,  s  =  and  hence  by  (monad)  ri,r2  H  M  C  :  By  (conversion). 


ri,r2  M:E 


By  Lemma  18,  there  exists  G  eT  such  that  F  By  /3-Subject  Reduction, 

Ti,T2,y:C  N:MG 


By  (let), 

ri,r2  h  let  yC^M  in  N:MG 

•  Assume  the  last  rule  is 

r,y:MB\-M:MB 
r  h  Fix  y.M  B.  M  :  M  B 

with  r  =  PijX  :  A,r2  and  x  0  FV(r2)  U  FV(fix  y:  M  B.M).  By  induction  hypothesis, 
there  exists  E  eT  such  that  E  =mi  M  B  and 

ri,r2,2/:MR  M:E 


By  Correctness  of  Types  and  Weakening, 


ri,r2  h  MB: 


By  (conversion), 

ri,r2,y  :  M  B  h  M  :  M  B 

and  by  (fixpoint), 

ri,r2  h  fixy:M  B.  M  :  M  B 


As  we  shall  see  later,  most  cubic  specifications  preserve  sorts. 
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4-5  Uniqueness  of  Types  and  Classification 

This  Subsection  is  concerned  with  properties  that  hold  for  some  specific  classes  of  MTSs. 
The  first  class  we  consider  is  that  of  functional  specifications. 

Definition  22  A  specification  S  =  (5,  A,  Tl)  is  functional  if  for  every  si,  S2,  S2,  S3,  S3  G 

(si,  S2)  G  .4  A  (si,  S2)  eA  S2  =  S2 

(si,  S2,  S3)  G  7^  A  (si,  S2,  s'^)  eU=^  $3  =  S3 
Functional  specifications  enjoy  uniqueness  of  types. 

Lemma  19  IfT  h  M  :  A  and  T  h  M  :  B  then  A  =mi  B. 

Proof  By  induction  on  the  structure  of  derivations.  ■ 

Uniqueness  of  Types  may  be  used  to  prove  preservation  of  sorts. 

Lemma  20  IfSis  cubic  and  functional  then  it  preserves  sorts. 

Proof  It  is  enough  to  show  that  for  every  4,  A'  in  /3-normal  form,  we  have 
r  A:s,r  A':s',  A=miA'  ^  s  =  s' 

Types  in  /3-normal  form  are  given  by  the  syntax 

U^S\B\  UVM.  W  I  M  W  I  nat 


where 

B  =  v\vr 

We  now  reason  by  induction  on  the  definition  of  U,  using  Uniqueness  of  Types.  ■ 

We  now  turn  to  Classification.  For  PTSs  the  result  is  traditionally  expressed  for  the  so- 
called  injective  specifications  and  states — among  other  things — that  for  every  M  G  T  and 
s,  s'  G  «S 

ri-M:4:s  A  r'l-M:4':s'  =?>  s  =  s' 

One  can  prove  a  similar  result  for  cubic  MTSs — using  preservation  of  sorts.  However 
several  MTSs  of  interest  are  not  cubic  and  the  statement  of  Classification  itself  is  overly 
strong  for  the  purpose  of  our  operational  semantics.  What  is  needed  is  a  stratification 
of  terms  in  the  usual  three  layers:  objects,  types  and  kinds — we  only  focus  on  cubic 
specifications.  ^ 


^  Note  that  one  may  probably  relax  the  assumption  =  {*”,  =t‘®}  in  the  statement  of  the  Lemma. 
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Lemma  21  (Classification)  Let  S  =  (<S,  72.)  be  a  cubic  specification  such  that 

S-^  =  Let  *  range  over  and  □  range  over  .  Define 

O  =  V*\00\0C\ AV*:C.  O  \  O  |  [0]  |  succ  C?  |  pred  C?  |  ifO  C>  O  O  | 

unit  O  I  let  V*:C  4=  C?  in  0  1  fix  V*:C.  O 
C  =V°\CO\CC\  XV*:C.  C  |  AV°:/C.  C  \  nV*:C.  C  \  nV°:/C.  C  |  nat  |  M  C 
K  =  *\nV*:C.IC\I[V°:JC.)C 

Then  0,C,}C  are  pairwise  disjoint.  Moreover, 

(i)  IfT  ^  M  :  A-.*  then  M  €  O; 

(a)  IfV  h  M  :  A:U  then  M  G  C; 

(Hi)  IfT  h  M  :  □  then  M  E  )C. 

Proof  By  using  properties  of  [.]  and  a  similar  classification  result  for  the  Calculus  of 
Constructions  with  fixpoints.  ■ 

It  follows  from  Subject  Reduction  that  for  every  M,N  in  T  such  that  M  is  legal  and 
M  -»Tni  TV  that 

MeX  =>  NeX 

for  X  ranging  over  O,  C,  K. 

4-6  Type-checking 

Type-checking  is  in  general  undecidable  because  we  cannot  check  convertibility  of  types. 
However,  type-checking  becomes  decidable  if  types  terminate. 

Definition  23  A  cubic  specification  S  =  is  non-dependent  if  for  every 

(si,  S2,  S3)  ^  72, 

Si  e  iS-*-  S2,  S3  € 

Non-dependent  cubic  specifications  have  normalising  types,  which  is  the  key  to  decidable 
type-checking. 

Proposition  24  Non- dependent  functional  cubic  specifications  have  decidable  type-checking 
provided  S,  A,  72  are  recursive. 

5  Operational  Theory 

In  this  section,  we  give  an  operational  theory  for  the  class  of  MTS  specifications  that 
we  consider  to  be  strictly  monadic.  The  goal  is  to  obtain  an  appropriate  notion  of 
MTSprogram  equivalence.  A  general  operational  theory  that  allowed  for  an  arbitrary 
monad  would  quite  difficult  to  develop.  As  a  first  step,  we  consider  only  the  computa¬ 
tional  effect  of  non-termination  as  expressed  by  the  lifting  monad. 

The  foundation  of  this  material  is  Gordon’s  work  [21]  on  an  operational  theory  for 
a  simply-typed  version  of  the  computational  with  inductive  and  co-inductive  types,  and 
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many  of  our  definitions  and  properties  are  minor  adaptations  of  Gordon’s.  The  main 
technical  challenges  in  scaling  up  Gordon’s  work  are  dealing  with  conversion  in  types  in 
kinds  and  handling  dependent  types. 

•  Conversion  in  types:  In  Gordon’s  presentation,  the  notion  of  a  type-indexed  relation  is 
used  in  many  places.  With  conversion  in  types,  this  becomes  more  complicated.  For 
example,  one  must  typically  show  that  the  type-indexed  relations  in  our  setting  are 
closed  under  conversion  of  types,  and  substitution  of  terms  in  types. 

•  Dependent  types:  With  dependent  type,  objects  may  occur  in  types  and  thus  many 
notions  regarding  substitution  and  contexts  become  more  complicated. 

5.1  Program  evaluation 

With  the  single  syntactic  category  of  pseudo-terms  in  MTSs  (as  adapted  from  PTSs), 
it  is  not  immediately  clear  how  to  define  a  notion  of  evaluation.  Classes  of  terms  that 
we  intuitively  understand  to  be  objects,  types,  and  kinds  all  belong  to  the  same  set. 
Normally,  only  objects  (which  express  computation)  should  be  evaluated. 

Given  this  mixing  of  terms  with  clearly  different  roles,  we  feel  that  is  it  important 
to  impose  order  by  considering  systems  arising  from  cubic  specifications.  Lemma  21 
(classification)  guarantees  that  terms  in  cubic  specifications  can  be  separated  into  disjoint 
classes  of  objects,  type  constructors,  and  kinds. 

Even  with  this  restriction,  dependent  types  introduce  complications.  With  dependent 
types,  objects  can  occur  in  types,  and  thus  type-checking  inevitably  requires  some  notion 
of  evaluation.  This  well-known  phenomenon  has  been  described  as  a  loss  of  distinction 
between  phases  of  type-checking  and  evaluation  [8]. 

Our  approach  to  handling  this  situation  is  to  simply  define  a  notion  of  evaluation  for 
well-typed  objects  resulting  from  cubic  specifications.  Specifically,  we  assume  that  type¬ 
checking  (by  whatever  means)  has  already  been  performed.  Thus,  for  example,  evaluation 
never  reduces  type  arguments  to  polymorphic  abstractions,  nor  does  it  evaluate  terms 
that  appear  in  types.  Any  such  manipulation  would  be  performed  by  type-checking.  The 
classification  implied  by  cubic  specifications  along  with  subject  reduction  guarantees  that 
the  class  of  objects  is  closed  under  evaluation  —  that  is,  evaluation  of  objects  need  only 
involve  objects. 

We  now  turn  to  the  following  definition  specifying  the  notions  of  program  and  program 
reduction  and  evaluation. 

Definition  25 

•  A  program  is  a  closed  object  M  with  a  closed  type,  i.e.,  it  is  an  object  M  where  there 
exists  an  A  such  that  •  h  M  :  A  :  =t=®  for  a;  €  {v,  c}. 

•  A  value  is  an  object  of  given  by  the  following  grammar: 

V  ::=\r{\  \  >(c:A.M  \  unit  M. 

•  An  experiment  is  an  object  context  (with  exactly  one  hole)  given  by  the  following 
grammar: 

jE::=succ«  |  pred*  |  ifO  •  M  AT  |  •  AT  |  let  a;:  A  4=  •  in  M 
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succ  [n]  I — Ymi  \n  +  ll 
pred  \n  +  1]  i — >mi  unit  |*n] 
pred  [0]  I — >rni  unit  [0] 
ifO  [0]  M2  Ms  I — >jni  M2 
ifO  \n  +  1]  M2  Ms  I — ^mi  Ms 

{><c:A.  Mo)  Ml  I — >mi  Mo{x  :=  Mi} 

fix  x:A.  M  I — >mi  M{x  :=  fix  x:A.  M} 
let  x:A<=  unit  Mi  in  N2  ' — >Tni  M2{x  :=  Mi} 

e  I — ^ml  ^ 

E[e]  I — >rni  E[e'] 

Fig.  17.  Program  reduction  rules 


[n]  }).  \n\  )x\A.  M  JJ-  >x:A.  M  unit  M  JJ-  unit  M 

succ  [n]  Jj.  [n  +  1]  pred|'n+l]  -Ij-  M  pred  [0]  .(j.  [0] 

M2  Ms 

ifO  fOl  Ma  Ms  y  ifO  \n  + 1]  Ma  M3  .11  V" 

Mo  J)-  )x.A.  Mq  Mo{x  :=  Ml}  .I}  V  M{x  :=  fix  x:A.  M}  V 
MoMii^-V  i\xx:A.M  i).  V 

M  unit  M'  N{x  :=  M'}  ^  V 
let  x:A^  M  \n  N  .Ij.  V 

Fig.  18.  Program  evaluation  rules 

•  A  confined  object  is  a  triple  (F,  M,  A)  such  that  M  is  an  object  and  F  h  M  :  A  is 
derivable 

•  Single-step  program  reduction  -  1 — >rni  •  is  the  smallest  relation  on  programs  satisfying 
the  rules  of  Figure  17. 

•  Big-step  program  evaluation  •  Jj.  •  is  the  smallest  relation  on  programs  satisfying  the 
rules  of  Figure  18. 
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We  write  M  -(1-  when  there  exists  a  V  such  that  M  JJ-  V  and  M  fl'  when  there  does  not 
exist  a  V  such  that  M  V. 

5.2  Strictly  monadic  specifications 

A  fundamental  property  of  monadic  frameworks  is  that  canonical  programs  have  value 
type.  Above  we  noted  that  canonical  programs  include  abstractions  —  and  thus  we  desire 
that  they  have  a  value  type  {i.e.,  they  belong  to  El*’').  To  ensure  this,  one  needs  to  consider 
a  restriction  on  specifications  that  forces  object  abstractions  to  be  typed  as  values. 

Definition  26  A  specification  72.  is  value  adhering  if  s'  —  for  every  (s,  s^)  G  72. 

We  have  considered  several  restrictions  on  specifications,  and  we  now  give  a  final 
restriction  that  captures  what  we  feel  are  the  natural  requirements  for  a  specification  to 
have  truly  monadic  character. 

Definition  27  A  specification  72.  is  strictly  monadic  if  it  is 

•  functional, 

•  cubic  and  S-^  =  {*",  *®},  and 

•  value-adhering. 

Thus,  a  strictly  monadic  specification  guarantees  uniqueness  of  types,  ensures  a  three- 
level  stratefication  into  objects,  constructors,  and  kinds,  and  forces  object  abstractions 
to  be  values  (observe  that  if  72  is  a  strictly  monadic  specification  and  M  N  eE\*  ,  then 
M  e  El*”) 

Throughout  the  remainder  of  this  section,  we  will  let  *  range  over  bottom  sorts 
and  □  range  over  top  sorts  S^. 

We  now  give  several  basic  properties  of  evaluation  under  strictly  monadic  specifica¬ 
tions. 

Proposition  28  Assume  that  72  is  strictly  monadic.  Let  L,  M,  N  be  programs  and  U,  V 
be  values. 

(i)  Program  reduction  is  deterministic:  if  L  i — ymi  Af  and  L  i — >rni  N  then  M  =  N. 
(a)  Program  evaluation  is  deterministic:  if  L  i}.  U  and  L  i}.  V  then  U  =  V. 

(Hi)  Values  are  the  canonical  forms  of  program  reduction:  if  -^3N  such  M  i — >rni  AT, 
then  M  is  a  value. 

(iv)  Suppose  M  i — >rni  N.  Then  for  any  V,  N  V  implies  M  ^  V. 

(v)  M  iffM  V 

Proof  Follows  the  same  structure  as  the  proof  by  Gordon  [21].  ■ 

Proposition  29  Assume  that  72  is  strictly  monadic. 

(i)  If  A:  then  A  nat,  or  A  -^rni  Tlx:B.  C  for  some  B,C  eT. 

(ii)  If  \-  A  :  *^  then  A  M  B  for  some  JB  G  T- 
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Proof  Proof  of  (1);  Necessarily  A  is  ^-strongly  normalizing.  Let  A'  be  its  /3-normal 
form.  By  Subject  Reduction  h  A' :  By  Generation  and  strict  monadicity,  A'  can  only 

be  nat  or  a  product  so  we  are  done.  The  proof  for  (2)  is  similar.  ■ 

The  following  property  formalizes  the  notion  that  programs  of  value  type  must  con¬ 
verge  to  a  canonical  program. 

Proposition  30  Assume  that  TZ  is  strictly  monadic. 

(i)  If  \-  M  :  A:  then  M  J|. 

(a)  If  M  :  nat,  then  M  -Ij-  [n]. 

(Hi)  //  h  M  :  Ux-.A.  B  :  then  M  >x:A'.  N. 

Proof  (1)  By  a  case  analysis  on  the  possible  shapes  of  M,  conclude  that  every  weak- 
head  reduction  sequence  starting  from  M  is  a  ^dt-reduction  sequence.  Hence  (by  strong 
normalization  of  /3i-reduction)  the  weak-head  reduction  sequence  starting  from  M  must 
end.  (2)  and  (3)  Again,  case  analysis  on  the  possible  shapes  of  M.  ■ 

Proposition  31  (program  type  inhabitation)  Assume  that  It  is  strictly  monadic. 

(i)  There  is  no  pseudo-term  M  s.t  •  h  M  :  nX:*".  AT.  Thus,  some  value  program  types 
are  uninhabited. 

(ii)  For  any  A  such  that  ■  A  :  there  is  a  B  such  that  •  h  Hx  x:\J[  B.  x  '.  A.  Thus, 

all  computation  program  types  are  inhabited. 

Proof  (1)  Without  loss  of  generality  we  may  assume  that  M  is  in  ^^-normal  form.  We 
proceed  by  a  case  analysis  on  the  possible  shapes  of  M. 

(2)  We  know  A  M  B  for  some  B  £T.  By  Subject  Reduction,  h  M  R  :  By 

(start),  X  :  M  B  \-  X  :  M  B.  By  (fixpoint),  h  fix  a::  M  R.  a;  :  M  R.  By  (conversion), 
h  fix  a::  M  R.  a; ;  A.  ■ 

Let  J-A  represent  the  program  fix  x;  M  B.  x  of  type  A  that  exists  (as  shown  above)  for 
any  AeT  such  that  h  A:*''.  We  write  ±  when  the  type  A  is  clear  from  the  context. 

5.3  Operational  equality 

We  now  establish  a  notion  of  operational  equivalence  applicative  bisimilarity  for  strictly 
monadic  MTSs  following  Gordon’s  elegant  presentation  of  a  similar  notion  for  a  simply- 
typed  version  of  the  computational  metalanguage  with  inductive/co-inductive  types  [21]. 
Given  the  definitions  below,  Gordon’s  proofs  [21]  carry  over  in  a  reasonably  straightfor¬ 
ward  manner.  Only  issues  regarding  substitution  and  type  equivalence  are  more  compli¬ 
cated,  and  we  indicate  some  of  the  interesting  points  below.  In  the  end,  we  can  show  that 
the  MTS  calculus  is  sound  w.r.t.  our  notion  of  operational  equivalence. 

Definition  32 

•  A  ground  relation  R  is  a  binary  relation  between  programs  of  the  same  type. 

•  A  confined  relation  is  a  binary  relation  between  confined  objects  of  the  same  type  in 
context  r.  Write  T  h  MUN  :  Ato  mean  that  (T  M  :  A)n{T  \-  N  :  A). 
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Definition  33  A  ground  relation  IZ  is  operationally  adequate  iff  for  all  programs  M,N, 
and  canonical  programs  V  where  •  h  M,  AT,  V  :  A: 

(i)  If  M  N  then  NUM. 

(ii)  IfM  JJ.  V  then  TIM. 

(iii)  M'^l■iffMT^_LA- 

(iv)  M  4)-  iff  for  some  V,  VIIM. 

We  often  need  to  consider  confined  relations  that  are  compatible  with  the  syntactic 
structure  of  objects.  Figure  19  introduces  a  special  notion  for  this  property  of  confined 
relations  called  compatible  closure.  All  the  rules  have  an  implicit  side  condition  that 
any  sentence  denoting  a  pair  of  confined  terms  is  well-formed.  Specifically,  a  sentence 
r  h  MUN  :  A  is  well-formed  if  F  h  M,  AT :  A.  Thus,  the  rule 

r  I-  MlT^A^l  :Ux:A.B  T  h  M2T^A^2  :A 

r  h  (Ml  M2)  n  {Ni  N2)  :  B{x  :=  M2} 

should  be  read  as  follows:  if  F  h  Mi,  A^i  :  Ha;:  A.  B  and  F  h  Mi  TZNi  :  IIx:  A.  B  and 
F  h  M2,  N2 :  A,  then  if  F  h  Mi  M2,  Ni  N2  :  B{x  :=  M2}  then  F  h  (Mi  M2)  TZ  {Ni  N2)  : 
B{x  :=  M2}.  Note  that  the  MTS  typing  rules  also  imply  F  h  A^i  Ar2  :  B{x  :=  Ar2}.  Then, 
by  uniqueness  of  types  we  have  B{x  :=  M2}  =mt  B{x  :=  N2}.  Thus,  by  the  conversion 
rule  for  compatible  closure  we  have  F  h  (Mi  M2)  TZ  {Ni  N2)  ■  B{x  :=  Ar2}. 

To  clarify  such  properties,  the  we  now  give  a  proposition  regarding  compatible  closure 
that  is  analogous  to  the  Generation  Lemma  (Lemma  14)  for  MTS  typing  judgements. 


Proposition  34  Let  IZ  be  a  confined  relation,  and  consider  judgements  of  the  form  F  h 

mUn  :  a. 

•  If  F  h  H  ^  N  : 

then  F  h  \n]TZ\n]  :  nat  and  A  =rni  nat 

•If  F  h  (succ  M)  IZ  (succ  N)  :  A, 

then  F  h  (succ  M)  IZ  (succ  N)  :  nat,  and  A  =mi  nat 

and  V  \-  MIZN  :  nat 

•If  F  h  (pred  M)  IZ  (pred  N)  :  A, 

then  F  h  (pred  M)  IZ  (pred  N)  :  nat,  and  A  =mi  nat 

and  T  \-  MIZN  :  nat 

•If  F  h  (ifO  Ml  M2  M3)  n  (ifO  Ni  N2  Ns)  :  A, 

then  F  h  (ifO  Mi  M2  M3)  %  (ifO  Ni  N2  N3)  :M  B  for  some  B 

and  A  =mi  M  B 

and  F  h  M^IZNi  :  nat,  F  h  M2IZN2  :  M  P,  and  F  h  M^IZN^  :  M  A. 
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r  h  xUx  :A  r  h  Tn]  ^  H  :  nat 

r  h  MIZN  :  nat  T  h  MUN  :  nat 

r  f-  (succ  M)  n  (succ  N)  ;  nat  T  h  (pred  M)  H  (pred  N)  :  nat 

r  h  MiUNi  mat  T  h  M27IN2  :  M  A  T  h  M^TlNz  :  M  A 
r  h  (ifO  Ml  M2  M3)'R(ifO  Ni  N2  N3)  :M  A 

T,x:A  h  MUN  :  B 
r  h  {>x-.Ai.M)n{>x\A2.N)  .Yix:A.B 

r,x:M  A  h  MTIN  :  M  A 
r  h  (fix  x:Ai.  M)  n  (fix  x:  ^3.  N)  :M  A 

r  MiTlNi  :Ux:A.B  , 

r  h  (Ml  M2)  H  {Ni  N2)  :  B{x  :=  M2} 

r  \-  MiHNi  :Ux:A.B 

- - - -  if  r  h  A  :  □ 

r  I-  (Ml  Ai)  n  {Ni  A2)  :  B{x  :=  ^1} 

r  h  MTIN  :A 
r  h  (unit  M)  TZ  (unit  N)  :M  A 

r  h  MiUNi  :  M  A 
T,x:A  h  M2nN2  :  M  B 

_ r  h  Aj  =mi  MA  fori  =  1,2 _ 

r  h  (let  x:-4i  4=  Ml  in  M2)  72.  (let  x:^2  ^  Ni  in  N2)  :  M  B 

T\-MnN:A  T\-A':s  A  =mi  A' 

T  h  MUN  :A' 

Fig.  19.  Compatible  closure  of  a  confined  relation 
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•If  T  {>oc:Ai.M)n{>x-.A2.N)  :  A, 

then  r  h  (Arr^i.  M)  11  (Ar:>l2.  N)  ;  Ux:B.  C  for  some  B  and  C, 
and  A  TlxiB,  Cj  Ai  ^fni  Bj  and  A2  ~~Tni  Bj 
and  T,x:B  h  M1ZN  :C. 

•If  r  h  (fix  x:Ai.  M)  n  (fix  x:A2.  N)  :  A, 

then  T  h  (fix  x:Ai.  M)1l{i\x  x:A2.  N)  :  M  B  for  some  B, 

and  A  —mi  M  B,  Ai  =mi  M  B,  and  A2  =mi  M  B, 

and  T,x:M  B  h  MIIN  :  M  B. 

•  If  r  h  {MiM2)n{NiN2)  :A, 
then  one  of  the  following  holds: 

(i)  r  h  (Ml  M2)  1Z  {Ni  N2)  :  B{x  :=  M2}  for  some  B, 

and  A  =mi  B{x  :=  M2}  and  A  =mi  B{x  :=  A^2}, 

and  r  h  MiUNi  :  Hx-.C.  B  and  V  \-  M2nN2  :  C, 

and  r  h  C  : 

(a)  r  h  (Ml  M2)  H  {Ni  N2)  :  B{x  :=  M2}  for  some  B, 

and  A  =mi  B{x  :=  M2}  and  A  =mi  B{x  :=  N2}, 
and  r  h  Mi  1Z  Ni  :  Ha;:  C.  B, 
and  r  h  C*  :  n. 

•If  r  h  (unit  M)  n  (unit  N)  :  A, 

then  r  h  (unit  M)  (unit  N)  :  M  B  and  A  =mi  M  B 

and  r  h  MUN  :B. 

•If  r  h  (let  x:Ai  ^  Ml  in  M2)  71  (let  x:A2  <=  Ni  in  N2)  :  A 

then  r  h  (let  x:Ai  4=  Mi  in  M2)  7^  (let  x:A2  <=  Ni  in  N2)  :  M  C 

and  A  =mi  M  C 

and  r  h  MiTlNi  :  M  B  andT,x:B  h  M2nN2  :  M  C 
and  r  h  yl,-  :  ♦  and  Ai  —mi  B  for  z  =  1, 2. 

Proof  By  induction  of  the  derivation  of  T  M1ZN  :  A.  ■ 

MTS  judgements  Vh  M  :  A  have  various  structural  properties  such  as  thinning,  con¬ 
densing,  etc.  that  were  presented  earlier.  The  definition  below  gives  analogous  properties 
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for  confined  relations,  and  we  will  need  to  verify  that  the  confined  relations  we  introduce 
do  indeed  satisfy  one  or  more  of  these  properties  (we  are  not  always  need  them  to  possess 
all  of  properties). 

Definition  35  (Properties  of  confined  relations) 

(i)  Type  Conversion: 

lfT\-MnN:A  and  T  h  :  s 
such  that  A  =mi  A' 

thenr  h  MTIN  :  A' 

(ii)  Context  Conversion: 

If  r  h  MTZN  :  A  and  F'  is  a  valid  context 
such  that  r  =fni  F' 

then  F'  h  MUN  :A 

(iii)  Thinning:  Let  F  and  A  be  legal  contexts  such  that  F  C  A.  Then 

F  h  M1ZN  :  A  implies  A  h  MTZN  :  A. 

(iv)  Condensing:  If  a;  ^  (FV(A)  U  FV(M)  U  FY{N)  U  FV{B)). 

T,x:A,A  h  MTZN  :  B  implies  F,  A  h  MTZN  :  B 

(v)  Spec: 

r,x:A,A  \-  M1TZM2  :B  k  T  [- N  :  A 

implies 

F,  A{a;  :=  N}  h  Mx{x  :=  N}TZM2{x  :=  N}  :  B{x  :=  N}. 

(vi)  Precong:  If  F  h  M,  N  :  A  and  F  h  C\M],  CfiV]  :  B  where  M,  N,  C[M]  and  C[N] 
are  objects,  then 

F  h  MTZN  :A  implies  F  h  C[M]TZC[N]  :  B. 

(vii)  Comp: 

F  h  MnN  :A  implies  F  h  MTZN  :  A 

(viii)  Sub-object: 

lfT,x:AA  h  MiTZNi  :B  and  F  h  M2TZN2  :A  and  F  h 
and  F,  A{a;  :=  M2}  =mi  T?  :=  A^2}  and  B{x  :=  M2}  =mi  B{x  :=  N2} 
then  F,  A{x  :=  M2}  L  Mi{x  :=  M2}TZNi{x  :=  iV2}  :  B{x  :=  M2} 
and  F,  A{a;  :=  iV2}  h  Mi{x  :=  M2}TZNi{x  :=  iV2}  :  B{x  :=  N2}. 
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(ix)  Sub-type: 

If  T,x:K,  A  MUN  :  B  and  rf-A,A':K  and  T\-Kn 
and  r,  A{a;  :=  A}  =mi  F,  A{a;  :=  A)  and  B{x  :=  A}  =rni  B{x  :=  A'} 
then  r,  A{x  :=  A}  h  Mi{x  :=  A}lZNi{x  :=  A'}  :  B{x  A} 
and  r,  A{ar  :=  -4'}  h  M\{x  :=  A\'R.Ni{x  :=  A'}  :  B{x  :=  A'}. 

Definition  36 

(i)  The  compatible  closure  of  a  confined  relation  TZ  is  the  confined  relation  7L  defined  by 
the  rules  in  Figure  19. 

(ii)  A  confined  relation  is  natural  iff  the  properties  Type  Conversion,  Context  Con¬ 
version,  Thinning,  and  Spec  hold  for  it. 

(iii)  A  confined  relation  is  a  precongruence  iff  the  rule  Precong  is  valid.  A  congruence 
is  a  confined  relation  that  is  both  a  precongruence  and  an  equivalence  relation. 

The  definitions  below  provide  a  way  to  induce  a  confined  relation  from  a  ground 
relation  and  vice  versa. 

Definition  37 

(i)  Let  r  be  a  legal  context.  Then  a  T-closure  is  a  substitution  a  defined  inductively  on 
the  size  of  F  as  follows: 

•  if  r  =  []  then  cr  is  the  identity  substitution,  and 

•  if  r  =  Xi  :  Ai, . . . ,  :  A„,  then  cr  is  a  simultaneous  substitution  {xi  :=  Mi, . . . , ,  : 

Mn)  such  that  for  every  i  G  {1, . . . ,  n}, 

h  Mi  :  Ai{xi  :=  Ml, . .  .,Xi-i  :=  Mi_i} 

(ii)  The  confined  extension  of  a  ground  relation  TZq  is  the  confined  relation  IZ  such  that 
(F  h  M1ZN  :  A)  iff  for  all  F-closures  a,  MaTZa 

(iii)  If  72^  is  a  confined  relation,  then  its  ground  restriction  is  the  ground  relation 

{(M,A)  I  •  h  MUN  :  A} 

(iv)  If  7^  is  a  confined  relation,  write  MUN  io  mean  a  pair  (M,iV)  is  in  the  ground 
restriction  of  TZ. 

The  definition  of  closure  is  slightly  more  complicated  than  other  presentations  because  in 
the  MTS  setting  one  must  take  dependencies  in  the  context  into  account  when  defining 
the  notion  of  closure.  The  following  proposition  establishes  that  the  notion  of  closure  that 
we  have  defined  above  is  the  correct  one  in  the  sense  that  it  generalizes  substitution  of  a 
single  closed  term. 

Proposition  38  Let  F  h  N  :  A.  For  all  T-closures  a,  h  Na  :  Act. 

Given  a  well-formed  context  F,  it  is  possible  that  there  exist  no  F-closures  due  to  the 
fact  that  some  types  may  be  uninhabited.  The  following  proposition  characterizes  when 
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closures  may  exist. 


Proposition  39 

•  //r  =  [•]  then  a  F -closure  exists  (namely,  the  identity  substitution). 

•  IfT  =  A,x:A  then  a  T -closure  exists  if  there  is  a  H-closure  a  and  a  term  B  such  that 

B:Aa. 

The  following  proposition  states  basic  properties  of  confined  relations. 

Proposition  40 

(i)  The  compatible  closure  of  any  reflexive  confined  relation  is  reflexive. 

(a)  The  confined  extension  of  a  ground  relation  is  natural. 

(Hi)  If%  is  a  ground  relation,  and  ifV  is  a  context  for  which  no  closure  exists,  then  for 
all  M,N  such  that  F  h  M,  N  :  A  F  \-  M  TZ  N  :  A. 

Component  (3)  reflects  the  fact  that  uninhabited  types  may  cause  terms  M,N  to  be 
trivially  related  by  the  confined  extension  of  a  ground  relation.  This  in  term,  means  that 
Condensing  does  not  hold  the  confined  extension  of  a  ground  relation.  Referring  to  the 
definition  of  Condensing  (see  Definition  35),  a  F,  x :  A,  A-closure  may  not  exist  due  to 
the  type  uninhabited  A  (and  thus  M  and  N  are  trivially  related),  but  a  F,  A-closure  may 
exist  that  causes  M  and  N  not  to  be  related.  This  illustrates  the  importance  of  working 
with  confined  relations  where  the  context  is  made  explicit. 

We  can  now  define  applicative  similarity,  the  ground  preorder  from  which  we  will 
define  operational  equality. 

Definition  41  Given  a  ground  relation  R,  let  the  ground  relation  [R]  between  programs 
of  the  same  type  A  be  defined  as  follows: 

•  h  M[R]N  :  A  iff  whenever  M  1).  [/  there  is  a  F  with  N  and  •  h  U  RV  :  A. 

An  applicative  simulation  is  a  relation  S  such  that  5  C  [5].  Define  ground  applicative 
similarity  <„  to  be  union  of  all  applicative  simulations.  Define  applicative  similarity  <a 
to  be  the  confined  extension  of  ground  applicative  similarity. 

Proposition  42 

(i)  Function  [•]  is  monotonic. 

(a)  The  identity  ground  relation  is  an  applicative  simulation. 

(Hi)  If  Si  and  S2  are  applicative  simulations,  then  so  is  SiS2- 

(iv)  Ground  similarity  is  the  greatest  fixed-point  of[-]  and  is  the  greatest  applicative  sim¬ 
ulation. 

(v)  •  h  M  <aN  :  A  iff  there  is  an  applicative  simulation  S  such  that  •  h  MSN  :  A. 

(vi)  Ground  applicative  similarity  is  a  preorder. 

Definition  43  An  applicative  bisimulation  is  a  relation  S  such  that  both  S  and  S~^ 
are  applicative  simulations.  Ground  applicative  bisimilarity  is  the  ground  relation  on 
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programs  of  type  A  such  that 

•  h  M ~a  AT  :  yl  iff  ■  \~  M  <aN  :  A  and  •  h  N  <aM  :  A. 

Applicative  bisimilarity  ~a  is  the  confined  extension  of  ground  applicative  bisimilarity. 
We  take  applicative  similarity  to  be  our  notion  of  equality. 

Since  ground  applicative  similarity  <„  is  a  preorder  (Proposition  42),  its  symmetric 
closure  ground  applicative  bisimilarity  a~a  is  an  equivalence  relation.  Furthermore,  for 
any  programs  M  and  N  of  type  A,  ■  h  M  iV  :  ^  iff  for  some  applicative  bisimulation 
5,  •  h  MSN  :A. 

Proposition  44  Ground  relations  <a  and  are  both  operationally  adequate. 

We  are  now  ready  to  prove  that  applicative  similarity  <„  is  a  precongruence  using  a 
technique  due  to  Howe  [29].  The  idea  is  to  define  another  relation,  compatible  similarity 
<c,  that  is  obviously  a  precongruence  and  obviously  contains  <„,  and  then  show  that  <a 
contains  <c  {i.e.,  the  two  relations  are  the  same). 

Definition  45  (compatible  similarity)  Define  the  confined  relation  compatible  simi¬ 
larity  <c  to  be  the  smallest  relation  closed  under  the  following  rule. 

ri-L<^M;A  T\-M<aN:A 

r  h  L<cN  :  A 

The  following  proposition  gives  a  number  of  properties;  the  last  is  the  desired  property 
that  <0  is  a  precongruence. 

Proposition  46 

(i)  Applicative  similarity  is  natural. 

(ii)  Confined  relations  <c  and  <c  are  reflexive. 

(Hi)  Confined  relations  <c  and  <„  both  imply  <c. 

(iv)  IfT  h  Ml  <cM2  :A  and  F  h  M2  <„M3  :  ^  then  P  h  Mi  <cM3  :  A. 

(v)  The  rules  Sub-object  and  Sub-type  (of  Definition  35)  hold  for  confined  relation 

<c- 

(vi)  If  •  h  U  <cM  :  A  for  value  U  then  there  is  a  value  V  such  that  M  i}.  V  and 
•  f-  U<cV  :A. 

(vii)  If  ■  h  M  <cN  :  A  and  M  JJ.  C/  then  •  h  U  <cN  :  A. 

(viii)  IfT  h  M<cN  :A  thenT  h  M<aN  :  A. 

(ix)  Applicative  similarity  is  a  precongruence. 

The  fact  that  applicative  similarity  is  a  precongruence  (and  applicative  bisimilarity 
is  a  congruence)  allows  us  to  reason  compositionally  about  MTS  programs.  Given  this, 
it  is  relatively  straightforward  to  show  that  the  equivalences  of  Figure  20  hold.  As  a 
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Congruence 

If  (r  h  M£aN  :A)  then  {T  h  Mc^aN  :  A). 

Canonical  Exclusivity 
If  (r  h  Uc^aV  :A)  then  {T  h  :  A). 

MTS  Calculus 

r  h  M)  Nc^aM{x  N)  :  A 

r  h  fix  a::  M.  N  ~o  N{x  :=  fix  x:  M.  N}  :  A 
r  h  let  a;:A  -^=  unit  N  in  Mc::^aM{x  :=  N}  :  A 
r  h  let  x:  A  M  in  unit  x^aM  :  A 
r  h  let  X2:A2  ^  (let  Xi:y4i  4=  Mi  in  M2)  in  M3 

— a 

let  Xi;^i  <=  Ml  in  (let  X2:A2  <=  M2  in  M3)  :  A 
r  I-  succ  [n]  ~o  [n  +  1]  :  A 
r  h  pred  \n  +  1]  fn]  :  A 
r  h  pred  [01  ~a  [01  :  A 
T  h  ifO  [01  Ni  iV2~aiVi  :A 
r  h  ifO  \n  +  11  Ni  N2  ^2  -  A 

Strictness  Law 
r  h  let  x:  B  in  M  ~o  -L  -  A 

Fig.  20.  Laws  of  equality  in  MTS 
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consequence,  we  have  that  MTS  calculus  is  sound  with  respect  to  operational  equivalence. 
This  result  provides  the  semantic  foundation  for  the  MTS  framework. 

Theorem  47  (soundness  of  MTS  calculus)  For  any  objects  M  and  N  such  that  F  h 
M  :  A  and  T  \-  N  :  A,  M  =rni  N  implies  M  N. 


6  Assessment  and  related  work 

Monadic  type  systems  may  prove  useful  in  several  applications,  some  of  which  are  sum¬ 
marized  below.  In  addition,  monadic  type  systems  may  find  applications  in  logic  but  we 
have  not  explored  this  possibility  thus  far. 

Intermediate  language  for  partial  evaluation; 

The  computational  metalanguage  is  well-suited  as  an  evaluation-order  independent 
intermediate  language  for  partial  evaluation  [27].  The  monadic  structure  guarantees  the 
soundness  of  partial  evaluation  in  the  presence  of  computational  effects  [32,48],  and  it 
facilitates  the  extension  of  type  specialization  to  a  language  with  first-class  references 
[14,30].  These  works  either  take  place  in  an  untyped  setting  [32],  or  in  a  simply  typed 
setting  [14,27,30]. 

We  expect  the  MTS-framework  to  contribute  to  the  definition  of  sound  partial  eval¬ 
uation  for  polymorphically  typed  languages  (where  specialization  with  respect  to  types 
coexists  with  specialization  wrt.  values  in  a  single  framework)  and  possibly  also  to  an 
extension  of  type  specialization  to  encompass  polymorphism.  It  would  also  be  interesting 
to  consider  type-directed  partial  evaluation  [11]  in  this  framework. 

Intermediate  language  for  compilation: 

Various  researchers  have  advocated  the  use  of  the  metalanguage  as  an  evaluation-order 
independent  intermediate  language  for  compiling  [7,28].  Many  features  of  the  metalan¬ 
guage  such  as  the  reliance  on  monads  to  encapsulate  effects,  and  the  use  of  pointed 
types  to  distinguish  call-by-name  from  call-by- value  and  certainly-converging  terms  from 
possibly-diverging  terms  have  been  incorporated  into  a  recent  proposal  for  a  simply-typed 
evaluation-order  independent  intermediate  language  [38]. 

We  believe  that  the  MTS  framework  and  the  results  of  this  paper  can  help  provide 
a  technical  foundation  for  combining  ideas  from  the  PTS-based  intermediate  language  of 
Meijer  and  Peyton  Jones  [31]  and  the  language  of  Peyton  Jones  et  al  [38]. 

Generic  CPS  translation  framework: 

Hatcliff  and  Danvy  [28]  have  developed  a  generic  framework  for  reasoning  about  CPS 
translations  of  simply-typed  languages  by  factorizing  the  translations  through  a  simply- 
typed  version  of  the  computational  metalanguage.  The  results  presented  in  the  present 
work  enable  us  to  generalize  this  idea  to  treat  in  a  single  framework  call-by-value,  call-by¬ 
name,  and  mixed  strategy  CPS  translations  for  PTSs.  The  general  translation  could  be 
instantiated  to  the  translations  for  F2  [23],  F^  [22],  non-dependent  PTSs  [10],  as  well  as 
the  recent  CPS  translations  for  PTSs  with  dependent  types  proposed  by  Barthe  et  al.  [6]. 
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7  Conclusion  and  directions  for  further  research 


The  paper  introduces  monadic  type  systems,  a  powerful  and  flexible  framework  to  capture 
computational  effects  in  rich  (polymorphic,  dependent)  type  systems,  and  study  opera¬ 
tional  semantics  for  monadic  type  systems  with  dependent  types. 

Much  work  remains  to  be  done.  For  example,  it  seems  important  to  extend  the  type 
structure  of  monadic  type  systems  with  further  constructs  as  the  type  structure  of  MTSs, 
with  only  two  type  constructors  (monads  and  dependent  products),  is  too  minimal  for 
some  applications. 

Section  5  presents  an  operational  semantics  for  MTSs,  which  smoothly  generalizes 
certain  aspects  of  Gordon’s  earlier  work  [21].  A  more  extensive  investigation  needs  to 
be  done  to  compare  applicative  similarity  to  other  familiar  notions  of  equivalence  such  as 
contextual  similarity.  In  addition,  the  semantics  is  mainly  concerned  with  the  lifting  mon¬ 
ads.  It  would  be  interesting  to  scale  up  alternative  semantics  for  notions  of  computation 
(see  e.g.,  [43])  to  the  framework  of  MTSs. 

Finally,  we  are  interested  in  exploiting  our  framework  for  CPS  translation  and  partial 
evaluation.  Based  on  the  technical  results  of  [6],  we  are  currently  extending  the  results 
of  [28]  to  MTSs. 
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Proofs 


A  Example  Compile-time  Transformation 

Consider  the  ML  source  term  {Xx.f@{\  ar))©(ref  5)  where  /  :  nat  ->  r.  This  term  is 


transformed  by  to 

let  Xi  : 

ref 

nat  — >•  M  r  C^|Ax./@(!  x)]  in 

let  X2  : 

ref 

nat  ^  C^|ref  5l  in  Xi  X2 

let  Xi  : 

ref 

nat  ->•  M  r  unit  Xx.C^lf®{\  x)J 

in 

let  X2  : 

ref 

nat  <=  (let  X3  :  nat  unit  5  in  refji^ 

nat  X3)  in  Xi 

X2 

let  xi  : 

ref 

nat  ^  M  T  unit  Ax. 

let 

0:4 

;  nat  — >  M  r  4=  unit  /  in 

let 

Xs 

:  nat  4=  (let  xe  :  ref  nat  <=  unit  x  in 

nat  Xe)  in 

X4  X5  in 

let  X2  : 

ref 

nat  ^  (let  X3  :  nat  4=  unit  5  in  refJ^^ 

nat  X3)  in  Xi 

X2 

ml 

let  Xi  ; 

ref 

nat  M  r  4=  unit  Ax. 

let 

X4 

:  nat  ->•  M  T  ^  unit  /  in 

let 

Xq 

:  ref  nat  4=  unit  x  in 

let 

X5 

:  nat  4=  nat  xe  in  X4  X5  in 

let  X3  : 

nat 

4=  unit  5  in 

let  X2  : 

ref 

nat  4=  ref  nat  X3  in  xi  X2 

^ml 

let  X2  : 

ref 

nat  4=  ref  nat  5  in 

(Aa^.let 

X5 

:  nat  Ijvf  nat  x  in  /  X5)  X2 

let  X2  : 

ref 

nat  4=  refjv^  nat  5  in 

let  X5  : 

nat 

;  !J^^  nat  X2  in  /  X5 

If  the  compiler  added 

special  rules  for  reasoning  with  state 

[44]  it  could  1 

derive  an  even 

more  optimized  program. 


let  X2  :  ref  nat  <=  refj^^  nat  5  in  /  5 

The  pervasive  type  annotations  in  the  program  can  guide  the  compiler  to  choose  good 
(unboxed)  runtime  representations  for  5  and  for  ref  5. 
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B  Strong  normalization  of  ///c-reduction 

B.l  Finiteness  of  Developments 

A  development  is  a  rewrite  sequence  in  which  the  contracted  redexes  are  descendants 
of  the  redexes  of  the  original  term.  A  standard  result  in  A-calculus,  called  Finiteness 
of  Developments,  shows  that  all  such  reduction  sequences  are  finite.  Among  the  many 
possible  proofs  of  FD,  one  proceeds  by  defining  underlined  A-terms.  We  take  this  path 
here. 

Definition  48  The  set  U  of  underlined  X-terms  is  defined  by  the  abstract  syntax: 

U  =  V  \  U U  \  XVM  \  iXV.U)U 

The  notion  ^  of  underlined  ^-reduction  is  defined  by  the  contraction  rule 

(Ax.  M)  N  M{x  :=  N} 

Finiteness  of  Developments  can  be  stated  as: 

Theorem  49  W  =  SN(^). 

B.2  Commuting  conversions 

In  order  to  prove  strong  normalisation  of  /x-reduction,  we  need  to  consider  a  commuting 
conversion 

Definition  50  The  notion  of  reduction  ^  is  defined  by  the  contraction  rule 

P  ((Ax.  Q)  R)  (Ax.  PQ)R 


provided  x  ^  FV(P). 

P'  preserves  strong  normalisation,  in  the  sense  that  underlined  A-terms  are  ^'-strongly 
normalising. 

Theorem  51  U  =  SN{0). 

Proof  Every  term  M  €  W  is  /3-strongly  normalising,  so  we  can  define  maxred(M)  to 
be  the  length  of  the  longest  yS-reduction  sequence  starting  from  M.  Now  assume  that 
M  ^  SN(^'),  so  we  have 

Af  A/i  ■  ■  ■ 

Without  loss  of  generality,  we  can  assume  that: 

(i)  N  6  SN(/?yd')  for  every  N  eU  such  that  maxred(A’)  <  maxred(M); 

(ii)  N  €  SN(/?;d')  for  every  strict  subterm  N  of  M. 

We  now  proceed  by  case  analysis  on  M.  Necessarily  M  is  of  the  form 

(Ax.  P)Q  R\  ...  Rn 
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Moreover,  the  first  reduction  step  M  Mi  is  a  ^'-step,  otherwise  we  would  reach  a 
contradiction.  There  are  four  possibilities7  out  of  which  we  treat  the  last  one  in  detail: 

•  M  -^p>  (Arc.  P')Q  Ri  ...  Rn  with  P  F. 

•  M  {\x.  P)Q'  Ri  ...  Rn  with  Q  Q'. 

•  M  -^p>  {Xx.  P)Q  Ri  ...  R'i  ...Rnlor:  some  i  with  Ri  R^. 

•  Q  =  (Ay.  S)  T  with  y  0  FV(P)  and  M  (Ay.  (Arc.  P)S)T  Ri  ...  Rn-  By  2,  each 
subterm  of  M  is  (0y3'-strongly  normalising,  so  necessarily  the  reduction  sequence  must 
contract  a  descendant  of  one  of  the  redexes  (Arc.  P)  S  or  (Ay.  (Arc.  P)  S)  T.  In  other 
words,  the  reduction  sequence  will  be  of  the  form 

(Ay.  (Ax.  P)S)TRi  ...  Rn  (Ay.  (Ax.  F)  S')  T'  R'^  ...  K 

->£  (Ax.  F)  {S'{y  :=  T'})  R',  ...K 

... 

or 

(Ay.  (Ax.  P)S)TRi  ...  Rn  -^pg  (Ay.  (Ax.  F)  S')  T'  R'l  ...  R'n 

-^p  (Ay.  {P'{x  :=  5'}))  T'  F,  . . .  K 

-^p  ... 

with  X  -^pp'  X'  for  every  term  X. 

•  The  first  case  is  impossible  since  M  -¥p  (Ax.  P)  (5{y  :=  T})  Ri  ...  Rn  and  hence 
by  assumption,  (Ax.  P)  {S{y  :=  T})  Ri  ...  Rn  6  SN {013').  On  the  other  hand, 
(Ax.  F)  {S'{y  :=  T'})  R'^  ...  R'^^  SN(^')  and  (Ax.  P)  {S{y  :=  T})Ri  ...  Rn 

(Ax. F)  (5"{y  :=  T'})  R'l  ...  R'n,  a  contradiction. 

•  The  second  case  is  impossible.  Indeed,  there  are  two  possibilities: 

P'{x  :=  5"}  ^  SN{00').  This  possibility  is  to  be  ruled  out  since  P{x  :=  <S}{y  := 
T}  €  SN{00')  by  rand  thus  P{x  :=  5}  G  S'N{00'),  which  together  with  P{x  := 
S'}  -^pp'  P"{x  :=  S"}  contradicts  P"{x  :=  S"}  ^  SN{00'). 
the  infinite  reduction  sequence  proceeds  further  as 

(Ay.  iP'{x  :=  S'}))  T'  R',  . . .  R'„  -^p_p>  (Ay.  {P"{x  :=  S"}))  T"  R'l  ...  ^ 

-^p  {P"{x:=S"}{y:=T"})R'l  ...  i?" 

->p  ... 

This  possibility  is  to  be  ruled  out  since  M  -^p  {P{x  :=  S}{y  ;=  T})  Ri  ...  Rn  so 
by  1,  (P{x  :=  S}{y  :=  T})  Ri  ...  Rn  e  SN{00'),  which  together  with  (P{x  := 
S}{y  :=  T})  Pi  ...  Rn  {P"{x  :=  S"}{y  :=  T"})  R'l  ...  P"  contradicts 

(P"{x  :=  S"}{y  :=  T"})  R'l  ...  R'i,  ^  SN(^'). 


C  Proof  of  Lemma  2 

Let  r  =  {yi  :  <71, . . . ,  y„  :  <7„}.  Let  further  T'  =  {yi  :  A;,  . . . ,  y„  :  A'^}  where  =  «S^lAi] 

if  yi  is  not  fix-bound  and  A^  =  C^|Ai]  otherwise.  Then 

(C.l)  r  hsML  e  :  T  ^  Gr,T'  \-  C^[el  :  C^[t] 
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using  Uml- 

Proof  The  proof  is  by  simultaneous  induction  on  the  type  derivation  of  an  expression 
using  the  auxiliary  inductive  hypothesis: 

(C.2)  r  hsML  v.T  =>  Gr,r'  h 

First  of  all,  (?r,r'  is  valid  since  for  all  yi  :  in  F'  Gr  H  :  s  where 

•  Hypothesis  (C.2)  is  immediate  for  F  \r^sML  i  *  riat,  since  Gv,^'  'r  i  :  V^[nat]  by  the 
presence  of  constants. 

•  Hypothesis  (C.2)  for  T,x  :  cr  \-sml  x  :  t  t  <  a.  Suppose  x  :  cr  in  F  with  a  = 
Vai . . .  On.r'  and  r  =  T'{ai  i-)-  Tj}.  Then 

(?r,r'  h  unit  (x  V^In]  . . .  :  C^lr] 

must  be  shown.  By  definition  of  F', 

Gr,F'  h  x:<S^[Vai...o„.r'l 

which  is  the  same  as 

Gr,T'  h  xiHoi:*".  . . .  Hon:*".  V^|r']. 

Hence 

Gr,F'  h  X  V^Inl  ...  rj]. 

•  Hypothesis  (C.2)  for  F,  /  :  r2  — >■  Ti  \-sml  f  '■  ti.  Hence  /  :  C^\t2  — >  ^i]  in  nnd 
we  have  to  prove 

Gr,r  h  Ay2  :  V^|r2l.let  yi  :  V^It2  nj  ^  f  in  yi  y2  :  C^[t2  Ti]. 

By  the  (application)  rule 

(C.3)  Cr,  F',  y2  :  ^^1x21,  yi  :  V^It21  ^  C^ln]  h  yi  y2  : 

and  by  the  assumption  on  / 

(C.4)  Cr,  r,  y2  :  h  /  :  C^[t2  ^  nl. 

Applying  (let)  to  (C.3)  and  (C.4)  yields 

Cr,  F',y2  :  h  let  yi  :  V^[r2  nj  4=  f  in  yi  y2  : 

And  the  claim  follows  by  (abstraction). 

Cr,F'  1-  Xy2  :  V^|r2].let  yi  :  V^[r2  -)•  ti]  ^  /  in  yi  y2  :  V^[r2  Ti]. 

•  Hypothesis  (C.2)  for  By  induction  and  S^{t2}  =  V^|r2], 

F  \-sML  Ax.e:T2->ri 

Gr,T',x:V^lT2}  h  C^[e]  : 

By  the  (abstraction)  rule 

Cr,r  I-  Ax  :  V'^lT2l.C'^[el  :  V’^It2] C^ln]. 

Since  V^Ir2|  ->■  C^|[ti]  =  V^[r2  n], 

Cr,F'  h  Ax  :  V^[T2l.C'^[el  :  V^lr2  -4  nj. 
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•  Hypothesis  (C.2)  for  e  .  r2  ti  induction  and  C^[r]  = 

r  hsML  fix  f.e  :  r2  Ti 

M  V^H, 

Gr,r',/  :  M  ^  rj  h  C^lej  :  M  V'^[r2  -?■  nj 
By  the  (fixpoint)  rule 

GrX  h  C'^Ifix  f.C^le}j  :  M  ->  n] 

and  by  (weakening) 

(C.5)  Gr,  r',  1/2  :  V^[t21  h  fix  f.C’^lej  :  M  V^[r2  ^  Ti}. 

As  seen  before, 

(C.6)  Gr,  T',  y2 :  yi  :  V'^Ir2l  ^  h  yi  y2  :  C^Iti] 

Apply  (let)  to  (C.5)  and  (C.6)  to  obtain 

(C.7)  Gr,r',y2 :  V^[r2l  h  let  yi  :  V^[t21  C^ln]  4=  fix  f.C^lej  in  yi  y2  :  C^ln] 
Apply  (abstraction)  to  (C.7) 

Gr,r',y2:  h 

Ay2  :  V'^[r2l.let  yi  :  V^[r2l  ^  C^lnj  ^  fix  f.C^[e]  in  yi  y2  :  V^[r2]  -> 

•  Hypothesis  (C.l)  for  values  T  \-sml  v:t.  By  the  auxiliary  inductive  hypothesis  (C.l), 

Gr,r'  h 

By  the  (unit)  rule 

Gr,r'  f-  unit  (V^M)  :  M  V^lr] 

and  by  the  definition  of 

Gr,T'  h  e^lvl-.C^lr]. 

r  \-SML  Cl  :  T2  — >•  Ti  r  h SML  ^2  ■  T2  .  , 

•  - - .  By  induction, 

r  \~SML  Cl  @62  :  Ti 

Gr,r'  h  C^leil  :  C^It2  nj  and  Gr,r'  h  €^{62}  :  C^It21 
By  rule  (application) 

(C.8)  Gr,  r',  yi  :  V^lT2j  ^  C^ln],  y2  :  V^lT2j  yi  y2 

By  rule  (let)  applied  to  the  inductive  hypothesis  for  62  and  (C.8) 

(C.9)  Gr,  r,  yi  :  ^  C^lnj  h  let  y2 :  V^[r2]  ^  €^[62}  in  yi  y2  :  C^It21 

and  again  by  rule  (let)  applied  to  the  inductive  hypothesis  for  Ci  and  (C.9) 

Gr,r  h  let  yi  :  ^  C^lnj  ^  C^IeJ  in 

let  y2  :  V^[r2]  ^  ^^[62]  in  yi  y2  :  C^[r2] 
since  C^|r2  ->  ti]  =  M  (V^[t2]  C^fri]). 
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r  \-sML  V’TI  r,x  :  gen(r,ri)  \-sml  e  :  T2 
r  ^SML  let  re  =  in  e  :  T2 

Call  a  =  gen(r,ri)  =  Vai . . .  VQ:„.ri.  By  induction  (C.2)  for  v 
(C.IO)  Gr,r'  h  V^lvj:V^ln} 

By  (weakening) 

(C.ll)  Gr.  r,  a, a„  I-  V"H  :  V"[t,] 

By  induction  on  n  find 

(C.12)  Gr,T'  h  Xai:*\...Xan:^rV^lvl:S^lal 

By  Lemma  1  there  is  an  s  €  jj}  such  that 
(C.13)  G,  h  :  s 

By  definition  of  gen(r,ri),  Gcr  is  included  in  Gr,  hence 
(C.14)  Gr  h  :  s 

By  induction  (C.l)  on  e  and  using  (C.14)  for  the  well-formedness  of  the  assumptions 
(C.15)  Gr,  r ,  rr  :  h  :  C^\t21 

Applying  (abstraction)  to  (C.15)  yields 

(C.16)  Gr, r  h  Arc  :  S^M-C^lel  :  C^lr2\ 

Apply  (application)  to  (C.12)  and  (C.16)  to  obtain 

(C.17)  Gr,  r'  h  (Arc  :  S^{alC^le\)  (A«i  Ac^n  :  :  C^{t2\ 

r  ^SML  Cl  :  nat  F  \-sml  62  :  t  F  \-sml 

- - - .  By  induction 

F  \-sML  ifO  ei  62  es  :  T 

(C.18)  Gr,F'  h  :  C'^Inatl 

and  for  i  =  2,3 

(C.19)  Gr,F'  h  C^leijiC^lrj 

and  by  (weakening)  and  the  definition  of 

(C.20)  Gr,  F', y  :  nat  h  :  M  V’^M. 

By  rule  (if) 

(C.21)  Gr,  F',  y  :  nat  h  ifO  y  €^{62}  €’^{63}  :  M  V^M 

Applying  (let)  to  (C.18)  and  (C.21)  yields 

(0.22)  Gr,  r'  h  let !/ :  nat  1=  C"lei]  in  ifO  y  C"[e3l  t  C"|7-] 


r  ^SML  :  nat 
F  \-sML  succ  e  :  nat 


By  induction, 


(C.23)  Gr,F'  h 

Starting  from  y  :  nat,  apply  rule  (succ) 

(C.24)  Gr,  F',  y  :  nat  I-  succ  y  :  nat 


and  then  rule  (unit) 

(C.25)  Gr,  r',  y  :  nat  h  unit  (succ  y) :  M  nat 

Now  recall  nat  =  V^lnatJ  and  hence  M  nat  =  C^|nat|  and  apply  (let)  to  (C.23) 
and  (C.25)  to  obtain 

(C.26)  Gr,T'  f-  let  y  :  nat  4=  C^[e]  in  unit  (succ  y)  :  C^[nat] 

•  The  case  pred  e  is  analogous. 


D  Proof  of  Theorem  5 

Suppose  Cl  ->  62  in  ML.  Then  C^|ei]  =mi  C^lea]. 

Proof 

•  case  ei  =  {\x.e)©v  and  62  =  e{x  :=  u}: 

=  let  yi  :  V^[t2  ->  n]  <=  C^l\x.e\  in  let  y2  :  V^|r2]  ^  in  yi  y2 

=  let  yi  :  V^\t2  ->•  n]  ■<=  unit  Aa: :  V^Ir2].C^[e]  in 
let  y2  :  V^[t21  unit  in  yi  y2 

>^ml  let  ya  :  V^[t2]  <=  unit  in  Xx  :  V^[T2l.C^Ie]  y2 

^rni  Arc  :  V^[r2].C^[el 
^ml  C^Ie]{rc  :=  V^H} 

For  62,  ^■^[62]  =  C^|e{rc  :=  u}]  which  is  =  to  C^|6]{rc  :=  V*^[wJ}  by  Lemma  23  since 

X  :  V^[rl. 

•  case  61  =  (fix  f.e)©v  and  62  =  e{f  :=  fix  f.e}©v: 

C^leij 

=  let  yi  :  V^[r2  ->•  n]  4=  C^|fix  f.e}  in  let  y2  :  V^[t2]  <=  C^lvj  in  yi  y2 

=  let  yi  :  V^[t2  nj  4=  unit  (Ay2  :  V^|t21. 

let  yi  :  V^[t2  n]  fix  /  :  C^[t2  ->  ti].C^[6]  in  yi  y2)  in 
let  y2  :  V^|t2]  4=  unit  in  yi  y2 

let  y2  :  V^|r2l  ^  unit  V^[v|  in  (Ay2  :  V^Ir2l. 

let  yi  :  V^|t2  ->■  ti]  ^  fix  /  :  C^[r2  ->  ti|.C^[6]  in  yi  y2)  y2 
(Ay2  :  V^Ir2l.let  yi  :  V^[t2  ^  n]  fix  /  :  C^[t2  ril.C^H  in  yi  y2)  (V^H) 
•-^m/  let  yi  :  V^|t2  ->  Ti]  4=  fix  /  :  C^[t2  ->  nl.C^Ie]  in  yi  (V^H) 

let  yi  :  VA^[t2  nj  ^  C^leJif  :=  fix  /  :  C^[ti  ^  ril.C^H}  in  yi  (V^H) 


63 


=  let  yi  :  V^|t2  ti|  <=  C^|e{/  :=  fix  f.e}}  in  let  y2  :  V^It2]  ^  C’^M  in  yi  y^ 

=ml  let  yi  :  V^[t2  Til  ^  C^[e{/  :=  fix  f.e}}  in  yi  (V^H) 

Here,  we  appeal  to  Lemma  22  to  obtain 

C^Mif  :=  fix  /  :  C^[r2  nl.C^Iel}  =  C^[e{/  :=  fix  f.e}} 

•  case  ei  =  let  a:  =  w  in  e  and  62  =  e{x  :=  u}: 

C^Ieil 

=  {Xx  :  S^l<7}.C^le})  {Xai  : 

e^Mix  :=  (Aai  a„  : 

Convertibility  =mi  to  V^Ie2]  follows  from  Lemma  24. 

•  case  ei  =  ifO  0  62  and  62  =  e^: 

C^Ieil 

=  let  y  :  nat  <=  unit  [0]  in  ifO  y  C^fe'iJ  C^[ey 

ifO  r^l 

•  case  ei  =  ifO  {i  +  1)  e'l  and  62  =  e^:  analogous. 

•  case  ei  =  succ  i  and  62  =  *  +  1: 

C^leil 

=  let  y  :  nat  unit  [i]  in  unit  (succ  y) 
unit  (succ  [i]) 

=mi  unit  \i  +  1] 

•  case  ei  =  pred  i  and  62  =  *  —  1:  analogous. 


Lemma  22  Suppose  T,  f  :  T2  ti  \-sml  e'  :  r'  and  T  \-sml  fix  /.e  :  T2  — ti  then 
C^le'if  :=  fix  /.e}l  =  C^Mif  :=  fix  /  :  C^[r2  Ti}.C^le}}. 

Proof  By  induction  on  e,  the  only  interesting  case  is  e'  =  /: 

C^lfif  ■=  fix  f.e}} 

=  C^[fix  /.el 

=  unit  (Ay2  :  V^[r2l.let  yi  :  V^[r2  -)■  Ti]  <J=  fix  /  :  C^|r2  ->•  ri].C^|el  in  yi  y2) 
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C^mu  :=  fix  /  :  C^lr2  rx].C^|el} 

=  unit  {Xy2  :  V^fraJ.let  yi  :  V^[t2  ->■  ti]  4=  /  in  yi  t/2){/  :=  f'x  /  :  C^It2  ->■  Ti].C^|e|} 
=  unit  {Xy2  :  V^|r2|.let  yi  :  V^|r2  — )■  TiJ  •<=  fix  /  :  C^[r2  — 7'il-C'^|e]  in  yi  2/2) 


Lemma  23  Suppose  V,x  :  t  \-sml  ^  ■  t'  <^‘^d  F  \-sml  =  t  then  C^|e{a;  :—  u}]  = 
C^lej{x  :=  V^H}. 

Proof  Induction  on  the  proof  of  r,a: :  r  \-sml  e  :  r'.  ■ 

Lemma  24  Suppose  r,a; :  Voi .  ..'ian.r  \-sml  e  :  r',  F  \-sml  v  :t,  ond  Voi . .  .Va:„.T  = 
gen(F,r)  then  C^[e{x  :=  u}}  =mi  C^le]{x  :=  Aoi  :  .  .a:„  : 

Proof  By  induction  on  e,  the  only  interesting  case  is  e  =  x,  r'  =  r{Q!j  :=  Tj}: 

C^lx{x  :=  u}l  =  :=  V'^Iril} 

C^lxjix  :=  Aoi  : 

=  unit  (x  V^lnl  . . .  V'^Ir^DIo;  :=  Aoi  :  . . .  a„  : 

=  unit  ((Aoi  On  :  ♦".V^|t;])  V^[ri]  . . .  V^|t„]) 

=mi  unit  (V^[t;l{a!i  :=  V^|Ti]}) 

■ 

E  Proof  of  Lemma  4 

Proof 

F  \-SML  e  :  T  r>  ■  A 
•  - .  By  induction, 

F  \-sML  ref  e  :  ref  T 

(E.l)  Gr,F'  h  C^[e]  :C^[r] 

By  Lemma  1  and  rule  (application), 

(E.2)  Gr,F'  h  refji^  :  V^[r]  ^  M  (ref  V^[rl) 

By  rule  (weakening) 

(E.3)  Gr,  T',  y  :  V^It]  h  ref.^,  M  (ref  V^H) 

By  rule  (application)  applied  to  (E.3)  and  y  :  V^|r], 

(E.4)  Gr,  F',  y  :  V'^Ir]  h  (refj^^  V'^Irl)  y  :  M  (ref  V'^Ir]) 

Finally,  apply  rule  (let)  to  (E.l)  and  (E.4) 

(E.5)  Gr,  F'  h  let  y  :  V^M  ^  in  (ref^^,  V^^H)  y  :  M  (ref  V^M) 

which  yields  the  claim  by  M  (ref  V^[r|)  =  C^[(ref  r)]. 
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r  \-sML  e  :  ref  T 


.  By  induction, 


r  \~SML  !  e  :  r 

(E.6)  GtX  H-  t\ 

By  Lemma  1,  rule  (application),  and  rule  (weakening), 

(E.7)  Gr,  r',  y  :  V^lref  r]  h  :  ref  V^lr]  ^  M  V^{t\ 

By  rule  (application)  applied  to  (E.7)  and  y  :  V^|ref  rj, 

(E.8)  Gr,  r',  y  :  V^lref  r]  h  (!^  V^{t})  y  :  M  V^fr] 

Finally,  apply  rule  (let)  to  (E.6)  and  (E.8) 

(E.9)  Gr,  r'  h  let  2/ :  V^[ref  r]  C^le]  in  (!j»^  V^H)  y  :  M  V^[r] 

which  yields  the  claim  by  M  V*^|r|  =  C^\t\. 


r  \-sML  Cl  :  ref  r  F  \-sml  62  "t  „  .  , 

•  - - - .  By  induction, 

F  \~SML  Cl  :=  62 :  () 

(E.IO)  Gr,F'  h  ;  C'^Iref  r] 

and 

(E.ll)  G'r,F'  h  C^le^j-.C^lrl 

By  Lemma  1,  rule  (application),  and  rule  (weakening), 

(E.12)Gr,r',yi:V"[refTl.!/2-.V«[rl  h  :=„  V"It]  :  ref  V"[t1|  ^  V"[t] -»  M  () 
Use  rule  (application)  twice  to  get 

(E.13)  C7r,F',yi  :  V^lref  rl,y2  :  V^lrj  h  (  V^lr])  yi  y2  :  M  () 

Apply  rule  (let)  to  (E.ll)  and  (E.13), 

(E.14)Gr,F',2/i  :  V^[ref  r]  h  let  y2  :  V^[r]  C^[e2l  in  (  :=^  V^H)  1/1  2/2  :  M  () 
Apply  rule  (let)  to  (E.IO)  and  (E.14)  to  obtain  the  claim 

Gr,F'  h  let  2/1 :  r]  ^  C^leiJ  in 


let  y2  :  V^|rl  4=  C^[e2l  in  (  :=j^  V^H)  2/1  2/2  :  M  () 

where  M  ()  =  C^[()l. 


F  Operational  Semantics  of 

The  small-step  operational  semantics  in  this  section  are  taken  from  work  by  Harper  and 
Lillibridge  [22,24].  Following  Felleisen  and  Hieb  [15],  each  of  them  defines  a  set  of  values  v, 
a  set  of  evaluation  contexts  E,  and  a  set  of  reduction  rules  to  be  applied  in  an  evaluation 
context. 
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F.l  Standard  Call-by-Name 

values 


V 


::=  Xx  :  a.e  \  Act :  K.e 
evaluation  contexts  E  ::=  [  ]  |  E®e  \  E[a] 

E[{Xx  :  o-.ei)@e2]  -^std-dm  E[ei{x  :=  62}] 

£?[(Aq!  :  K.e)[a]]  -^std-dm  E[e{a  :=  a}] 

F.2  Standard  Call-by-Value 

values  V  x\Xx-.  a.e  \  Aa  :  K.e 

evaluation  contexts  ::=  [  ]  |  |  v^E  \  E[a\ 

E\{Xx  :  (T.e)@u]  -^std-cbv  E[e{x  :=  u}] 

£'[(Aq!  :  /«.e)[(T]]  -^std-cbv  E[e{a  :=  a}] 

F.3  ML-style  Call-by-Value 

values  V  ::=  x  \  Xx  :  a.e  |  Aa  :  k.v 

evaluation  contexts  E  ::=  [  ]  |  E®e  \  v©E  \  Aa  :  k.E  \  E[a\ 

E[{Xx  :  a.e)®v]  -^mi-cbv  E[e{x  :=  u}] 

£'[(Aq:  ;  K.u)[a]]  -^mi-cbv  E[v{a  :=  a}] 
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Abstract 

We  adapt  Kahn-style  (“big-step”)  natural  semantics  to  taJce  on  desirable  aspects 
of  small-step  and  denotational  semantics  forms,  more  precisely:  (i)  the  ability  to 
express  divergent  computations;  (ii)  the  ability  to  reason  about  the  (length  of  a) 
computation  of  a  derivation;  and  (Hi)  the  ability  to  compute  upon  and  reason  about 
higher-order  values.  To  accomplish  these  results,  we  extend  the  classical,  inductive 
interpretation  of  natural  semantics  with  coinduction  mechanisms  and  use  “negative” 
rules  to  express  divergence.  A  simple  reformatting  of  the  syntax  of  derivations  allows 
a  simple  description  of  the  “length”  of  a  derivation.  Finally,  the  recoding  of  closure 
values  into  denotational-semantics-like  functions  lets  one  embed  derivations  within 
closures  that  embed  within  derivations;  in  this  sense,  the  semantics  becomes  “higher 
order.”  Examples  are  given  to  support  the  definitional  developments. 


Kahn-style  (“big-step”)  natural  semantics  [9]  captures  a  program’s  entire 
computation  within  a  single  derivation.  This  representation  is  more  compact 
than  what  one  obtains  from  state-transition,  “small-step,”  and  denotational 
definitions;  in  addition,  natural  semantics  provides  several  additional  attrac¬ 
tions: 

•  When  the  natural  semantics  is  defined  in  “environment  form,”  that  is,  the 
semantics’  propositions  are  ternary  relations  of  the  form,  /?  h  e  JJ-  u,  where 
p  €  Environment,  e  €  Expression,  and  v  G  Value,  the  resulting  deriva¬ 
tions  are  (almost  always)  semicompositional.  That  is,  when  one  draws  a 
physical  derivation  tree  starting  from  an  initial  source  program  eo  and  ini¬ 
tial  (empty)  environment  Pq,  then  every  node  within  the  tree  has  the  form 
p'  f-  e'  .IJ.  v',  where  e'  is  a  subphrase  of  Cq.  See  Figure  1  for  an  example. 
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versity  scholarship;  Schmidt  is  supported  by  NSF  CCR-9633388. 
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Let  p3  =  /£)  ©  {x  3}  in  the  following: 

p  h  (Ax.a:)(l  +  2)  11 3 

/  i  \ 

p  h  (Ax.a;)  iy{p,x,x)  p  I-  1  +  2  3  pz\-  x  3 

ph^l-l  ^2112 


Fig.  1.  A  semicompositional  derivation  tree 


•  One  can  prove  concisely  properties  of  convergent  derivations  by  induction 
on  the  height  of  the  derivation  tree. 

•  Static  analyses  are  simple  to  formalize.  The  key  concept,  a  program’s  col¬ 
lecting  semantics  [2,13,15],  is  defined  as  a  simple  function  of  the  program’s 
derivation:  Given  a  program,  cq,  its  initial  environment,  po  and  its  result¬ 
ing  derivation  tree,  d,  define  the  collecting  semantics  of  subphrase  e  of  Cq  in 
d  to  be  Collecting{d,  e)  =  {p  \  p  h  e  Jj-  u  is  a  node  in  d}. 

Alas,  natural  semantics  is  imperfect:  One  cannot  reason  about  divergent  pro¬ 
grams,  and  its  inherent  first-ordered-ness  makes  natural  semantics  a  poor 
choice  for  analysis  of  “open”  or  “modular”  programs.  Both  denotational  and 
small-step  semantics  hold  advantages  in  these  regards. 

In  this  paper,  we  modify  natural  semantics  to  take  on  attractive  aspects  of 
small-step  and  denotational  semantics  without  losing  its  attractive  features. 
The  features  we  wish  to  gain  are 

•  One  should  be  able  to  express  divergent  computations. 

•  One  should  be  able  to  reason  in  terms  of  the  length  of  a  computation, 
whether  the  computation  is  convergent  or  divergent. 

•  One  should  be  able  to  reason  about  “higher-order”  values,  e.g.,  closures. 

We  achieve  our  goals  for  a  subset  of  natural  semantics  definitions  that  we  call 
L-attributed — that  is,  left-to-right  processing.  L-attributed  natural  semantics 
definitions  have  a  natural  notion  of  sequential  computation  from  left-to-right 
that  resembles  the  computations  done  with  a  small-step  semantics  or  with 
a  Prolog  interpreter  applied  to  the  natural  semantics  rule  schemes  [4].  In 
addition,  we  can  discuss  the  “length”  of  a  computation. 

To  gain  divergent  computations,  we  generate  sets  of  “positive”  (conver¬ 
gent)  and  “negative”  (divergent)  rules  from  the  natural  semantics  rule  schemes 
[3,14,13]  and  apply  coinduction  definition  techniques  to  the  negative  rules. 
Finally,  we  modify  the  structure  of  higher-order  values — closures — so  that 
instead  of  being  inert  values,  closures  become  “alive”  by  containing  partial 
derivations.  This  allows  denotational-semantics-like,  extensional-style  reason¬ 
ing  and  opens  the  door  to  the  application  of  partial  evaluation  techniques  [5,8] 
to  natural  semantics  definitions  [7]. 
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1  L-attributed  Natural  Semantics 

Recall  that  an  L-attributed  attribute  grammar  [10]  is  a  Knuthian  attribute 
grammar  where  information  flows  from  left  to  right;  thus,  the  attributes  for  a 
parse  tree  can  be  calculated  in  a  single,  left-to-right,  tree  traversal. 

Analogously,  we  define  an  L-attributed,  environment-based,  natural-semantics 
rule  scheme  as  follows.  A  scheme  of  the  form 

pi  h  Cl  D-  Ui  /O2  l~  4  ^  ^2  •  •  • 

Po  I-  op{ei,  62,  ...,  e„)  JJ.  Vm+\ 

is  L-attributed  if 

•  the  value  of  each  pi  is  a  function  of  61,62,  and  those  pj  and  Vj  such 

that  j  <i 

•  the  value  of  each  e\  is  a  function  of  61, 62, ...,  6„,  and  those  pj  such  that  j  <i 
and  those  Vj  such  that  j  <i 

•  the  value  of  Um+i  is  a  function  of  ci,  62,  c„,  and  those  pj  and  vj  such  that 

j  <m  +  l 

Again,  the  intuition  is  that  a  derivation  with  an  L-attributed  rule  can  be 
formulated  by  a  left-to-right  tree  traversal,  where  the  p^-values  are  the  “inher¬ 
ited  attributes”  and  the  Uj-values  are  the  “synthesized  attributes.”  But  the 
rule  scheme  is  a  true  attribute-grammar  rule  only  if  m  =  n  and  ej  =  Cj,  for 
all  1  <  i  <  m.  This  need  not  be  the  case — the  standard  rule  for  function 
application  is  a  counterexample: 

p  h  61  ij-  {p',  x',  e')  p  I-  62  4  ^2  p'  ®  U2}  b  6^  ij-  u 

P  h  61  62  -D-  U 

Virtually  every  natural  semantics  definition  in  common  use  is  L-attributed. 

Assuming  that  no  pi  or  Vm-i-i  manufactures  new  source  program  syntax, 
it  is  straightforward  to  prove  that  a  set  of  L-attributed  rule  schemes  forms 
a  semicompositional  definition.  (Indeed,  L-attribution  is  unimportant  to  the 
proof.) 

2  Positive  and  Negative  Rules 

Although  it  is  traditional  to  take  an  inductive  interpretation  of  natural  seman¬ 
tics  rule  schemes,  we  desire  derivations  for  divergent  programs,  so  we  interpret 
each  L-attributed  rule  scheme  as  inducing  positive  and  negative  rules,  in  the 
sense  of  Cousot  and  Cousot  [3,13]:  An  L-attributed  rule  scheme  induces  a 
family  of  positive  rules  of  the  form 

Plt-Cid-Ui  P2be2]|-U2 

po  t-  Op(ei,  62,  ...,  6„)  0-  Vm^i 
and  m  families  of  negative  rules  of  the  form 

_  Pi  b  e[  JJ.  vi  pfc-i  H  e'^_i  .[I  Vk-i  Pk^  it 
Po  h  0p(6i,  ...,  6n) -O' 
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If  desired,  you  can  read  the  above  as  generating  one  positive  rule  scheme  and 
m  negative  rule  schemes,  but  it  is  traditional  to  generate  the  set  of  substitution 
instances  (rules)  of  a  rule  scheme,  hence  we  speak  of  one  family  of  positive 
rules  and  m  families  of  negative  rules. 

The  positive  rules  derive  convergent  computations  and  the  negative  rules 
derive  divergent  ones.  We  define  the  convergent  derivations  to  be  the  inductive 
(least-fixed  point)  interpretation  of  the  positive  rules.  ^  Next,  we  define  the 
divergent  derivations  by  using  the  convergent  derivations  plus  a  coinductive 
(greatest  fixed-point)  interpretation  of  the  negative  rules.  ^  The  set  of  well- 
formed  derivations,  wfd,  of  the  natural  semantics  is  the  union  of  the  convergent 
and  divergent  derivations. 

With  the  inductive  interpretation  of  the  positive  rules  comes  inductive 
reasoning  principles,  most  notably  induction  on  the  height  of  the  convergent 
derivations,  and  with  the  coinductive  interpretation  comes  coinductive  rea¬ 
soning. 

3  Modifying  the  Rules  into  a  “Smaller-Step”  Format 

A  user  of  a  natural  semantics  starts  with  an  initial  environment,  program 
pair,  po,  Cq,  and  wants  to  draw  a  derivation.  When  she  starts,  the  user  has  no 
clue  whether  a  convergent  derivation,  po  -Ij-  u,  or  a  divergent  derivation, 
Po  b  Co  'O',  will  develop.  The  usual  hack  is  to  employ  a  Prolog-style  “logical 
variable,”  V,  to  denote  either  of  JJ-  u  or  -O',  and  start  writing  a  derivation  with  a 
root  of  form  po  b  cq  -IJ-  V.  But  this  is  an  imperfect  start  and  fails  to  accurately 
deal  with  divergence — a  formalization  should  do  better. 

We  make  the  big-step,  natural  semantics  into  a  “smaller  step”  one — based 
on  the  intuition  that  the  triple,  Po  b  Cq  ■IJ'  u,  asserts  the  existence  of  a  finite 
derivation  of  small  steps,  (po  b  cq)  ->•*  u,  we  propose  this  new  grammar  for 
“raw  derivations”: 

d  €  Derivation 
s  €  Sequent  (p  b  e) 

v  G  Value  (Note:  assume  Sequent  D  Value  =  0) 

s 

d  ::=  V  \  df^'  ^dn,  n  >  0 

That  is,  a  derivation‘s  is  a  value  (e.g.,  an  integer  or  a  closure),  or  a  tree  whose 
root  is  a  sequent,  s  (that  is,  p  b  e),  and  whose  subtrees  are  derivations.®  If 
a  sequent,  s,  has  a  sequence  of  computation  steps  that  converge  at  v,  then 

^  The  L-attributed  positive  rules  are  continuous. 

^  The  L-attributed  negative  rules  are  cocontinuous. 

^  Starting  with  a  universe  of  finitely  branching  trees  of  at  most  countably  infinite  depth, 
we  take  the  coinductive  definition  of  the  grammar  rule  for  Derivation. 

®  We  will  also  write  this  in  the  linear  form,  s{di,  ...,dn). 
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Let  ps  =  p  ©  {x  i->  3}  in  the  following: 

/)  h  (Ax.x)(l  +  2) 

y  {  \  \ 

p  h  (Ax.x)  phl  +  2  p3\-  X  3 

(/9,  p  p\-  2  ^3  ^3 

Fig.  2.  Sample  derivation  in  modified  syntax 


the  corresponding  derivation  will  have  s  at  the  root  and  have  as  its  rightmost 
child  subtree  the  leaf,  v.  Figure  2  displays  a  small  example:  Such  trees  bear 
a  relationship  to  the  ones  derived  with  Plotkin-style,  “small-step,”  structural- 
operational  semantics  rules  [11],  once  one  notes  that  the  arrows  from  sequent 
to  sequent  represent  “congruence”  steps  whereas  the  arrows  from  sequent  to 
value  represent  “/d(5”  steps.  Indeed,  based  on  this  intuition,  one  can  mechani¬ 
cally  reformat  the  derivation  tree  into  a  Plotkin-style  derivation  by  traversing 
and  disassembling  the  derivation  from  left  to  right.  This  idea  provides  the 
intuition  for  the  development  in  the  next  section. 

Importantly,  a  divergent  program  will  have  a  derivation  with  an  infinite 
path;  specifically,  the  derivation’s  rightmost  path  will  be  infinite,  because  the 
negative  rules  were  formulated  from  L-attributed  rule  schemes. 

From  this  point  onwards,  we  work  with  the  syntax  of  derivations  defined 
above,  and  we  use  wfd  C  Derivation  to  denote  the  set  of  well-formed  deriva¬ 
tions  under  the  new  syntax. 

Here  is  some  additional  useful  metanotation:  We  use  p\-  e  \.v  and  p  h  e  t 
as  follows: 

•  p  h  e  4-  denotes  a  derivation,  d,  such  that  root{d)  =  p  h  e  and  the 
rightmost  subtree  of  d  is  the  leaf,  v 

•  p  h  e  t  denotes  a  derivation,  d,  such  that  root{d)  =  p  h  e  and  the  rightmost 
subtree  of  d  is  not  a  value. 

This  metanotation  gives  us  a  trivial  representation  of  the  new  formats  of 
positive  and  negative  rules.  Given  this  natural  semantics  rule  scheme. 

Pi  V-e\^Vi  p2^e'2^V2  "•  Pm  P  -U- 

PO  P  Op(ei,  62,  ...,  e,j)  JJ-  lljn+l 
the  positive  rules  we  induce  have  the  form 

^  Pl\-  e\\.Vi  P2  P  e'a  4-  U2  •  •  •  Pm  P  Cm  Vm  Vm+\ 

Po  P  op(ei,e2,...,e„) 
and  the  negative  rules  now  appear 

_  Pi  P  e\  4-  v\  Pk-i  P  4-1  i  Pfc  efc  t 

Po  P  op(ei,...,e„) 

for  all  k  G  l..m.  Remember  that  p  P  e  4-  and  p  P  e  t  describe  deriva- 
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p  h  (Aa:.a;)(H- 2)  p  I- (Ax.x)(l  +  2)  p  h  (Ax.x)(l  +  2)  p  h  (Ax.x)(H- 2) 

^  ^  /  ^  /  \ 

p  h  (Ax.x)  P  I-  (Ax.x)  p  I-  (Ax.x)  p  h  1  +  2 

(p,x,x)  (p,x,x) 

Fig.  3.  The  first  four  stages  of  a  development 

tions  (not  just  sequents),  therefore  the  rules  resemble  Prawitz-style  natural 
deduction  rules  [12],  where  antecedents  are  derivation  trees  and  succedents 
are  sequents/propositions. 

It  is  easy  to  prove  that  the  set  of  derivations  of  the  modified  rules  is 
isomorphic  to  the  set  of  derivations  of  the  original  rules. 

4  Derivation  Discovery 

The  previous  two  sections  defined  the  “semantics  of  natural  semantics,”  namely, 
how  the  original  natural  semantics  rule  schemes  induce  families  of  positive  and 
negative  rules  and  how  the  rules  are  used  to  define  wfd,  the  set  of  well-formed 
derivations. 

But  users  use  rule  schemes  to  compute  derivations — starting  from  an  initial 
sequent,  po  P  eo,  a  user  computes,  step  by  step,  a  derivation  tree.  Using  the 
new  syntax  of  derivation  trees,  defined  in  the  previous  section,  the  process  of 
derivation  discovery  becomes  simple  and  natural:  One  uses  the  original,  L- 
attributed  natural  semantics  rule  schemes  to  draw  a  derivation  in  incremental 
steps  as  a  left-to-right  tree  traversal — there  is  no  need  for  Prolog-style  “logical 
variables.”  To  state  this  more  precisely,  an  original,  L-attributed  rule  scheme. 

Pi  h  e'l  li  P2  P  4  ^2  •  •  •  Pm  P  jl- 

Po  h  op(ei,  62,  e„)  IJ.  Vm+l 

directs  the  traversal  as  follows: 

(i)  Starting  from  the  “goal  sequent,”  po  h  qp(ei,e2,...,e„),  generate  an  arc 
to  the  “subgoal,”  pi  h  e[-,  attempt  to  “satisfy”  the  subgoal  by  drawing  a 
convergent  derivation,  pi  h  e[  ^  vi. 

(ii)  Once  the  subgoal  is  achieved,  repeatedly  generate  and  attempt  to  satisfy 
subgoals  Pi  h  6^,  for  1  <  i  <  m. 

(iii)  When  all  subgoals  are  achieved,  compute  ^^+1  and  attach  this  to  the 
derivation  as  the  rightmost  child  of  the  root,  po  P  op(ei,e2,  ...,e„). 

For  example,  the  discovery  of  the  derivation  in  Figure  2  would  start  with 
the  steps  drawn  in  Figure  3  and  would  proceed  in  similar  increments  until  the 
tree  in  Figure  2  results.  We  call  a  sequence  of  such  partial  derivation  trees  a 
development.  Informally  stated,  a  development  is  complete  if  while  working 
from  left  to  right,  one  reaches  a  derivation  that  belongs  to  wfd.  A  finite 
development  might  not  be  complete,  and  a  complete  development  might  not 
be  finite:  In  the  first  case,  an  error  in  the  source  program,  e.g.,  po  h  2  -f  true, 
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can  cause  an  unwanted  termination  in  the  development. 

In  the  second  case,  this  rule  scheme,  ^  {l  ^  >  would  of  course  generate 

this  positive  and  this  negative  rule; 

p\-loop\.v  V  p  h  Zoop  t 
p  h  loop  p  h  loop 

Using  these  rules,  we  obtain  from  the  starting  sequent,  po  h  loop  + 1,  this 
infinite  derivation 

po  h  loop  +  1  — >  Po  h  loop  — y  Po  h  loop  — >  •  •  • 

The  derivation  is  well  formed  because  the  rule  scheme  for  arithmetic  addition, 

namely,  ^  Pj~  ^2  generates  positive  rules  of  this  form 

p  h  ei  +  62 -U- pZus(ui,  U2) 

pheijvi  pi- 62 1 ^2  plus(vi,V2) 

p  h  61  +  62 

and  negative  rules  of  these  two  forms 

_  p  I-  Cl  t  _  pheilui  pH  62! 

'pl“  61+62  p  1-61 +62 

and  the  first  form  of  negative  rule  justifies  that  the  derivation  is  well  formed, 
that  is,  it  is  a  member  of  wfd. 

Figure  4  gives  formalizations  of  when  a  raw  derivation  is  partially  devel¬ 
oped  and  is  completely  developed.  An  important  consequence  of  the  defini¬ 
tions  is  that  left-to-right  derivation  discovery  generates  a  sequence  of  partially 
developed  trees.  When  the  sequence  completes,  the  result  is  a  complete  de¬ 
velopment. 

4.1  Semantics  of  Developments 

Figure  4  defines  the  crucial  aspects  of  developments,  and  several  easily  proved 
consequences  follow.  First,  here  is  a  simple  semantics  of  developments:  Given 
a  development,  do  =+  di  •  •  •  =+  di  =+  •  •  •,  define  the  set  of  derivations 
denoted  by  a  partial  derivation,  di,  to  be  Si  =  {d  €  wfd  \  d  extends  dj}. 
That  is,  each  dj  defines  the  set  of  those  well-formed  derivations  whose  prefix 
is  dj.  For  all  j  >  i,  Sj  C  Si.  The  semantics  of  a  complete  development  is 

Sij  =  Ploo 

With  this  semantics,  we  have  easy  proofs  of 

•  soundness:  every  completely  developed  derivation  is  well  formed,  that  is,  it 
is  a  member  of  wfd 

•  adequacy:  every  d  €  wfd  has  a  complete  development 

Soundness  follows  because  the  limit  of  a  complete  development  is  a  deriva¬ 
tion  that  belongs  to  5^,;  adequacy  holds  because  the  natural  semantics  is 
L-attributed,  hence  every  well-formed  derivation  must  have  a  complete  de¬ 
velopment  that  is  a  sequence  of  partial  derivations  drawn  in  a  left-to-right 
traversal. 
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isPartial{v) 

isPartial{s(di,  ...,dk))  iSO  <k  <m  and  there  exists 

I  .di  •  •  •  dk  dk+i  •  •  •  dffi 

^  •  s 

such  that  for  all  0  <  j  <  k,  is  Complete^  {dj),  and  isP  artial{dk) 
(Take  greatest  solution  of  this  definition.) 

isComplete^  (v) 

isComplete^ {s{d\,  ...,dm))  iff  there  exists  +  : 

such  that  for  all  0  <  j  <  m,  isComplete^{dj) 

(Take  least  solution  of  this  definition.) 

isComplete{v) 

isComplete{s{di, ...,  dm))  iff  there  exists  ± 

such  that  for  all  0  <  j  <  m,  isCoTnplete^{dj),  and  isComplete{djn) 
(Take  greatest  solution  of  this  definition.) 

Fig.  4.  Definitions  of  partially  and  completely  developed  derivations 


Hence  the  set  of  well-formed  derivations,  wfd,  is  characterized  by  the  set  of 
complete  developments.  As  a  result,  one  obtains  a  small-step-semantics-like 
induction  principle:  induction  on  the  length  of  a  complete  development. 


5  Higher-Order  Natural  Semantics 

Traditional  natural  semantics  is  “too  first  ordered” — ^values  like  closures,  (p,  x,  e), 
are  inert,  “dumb,”  data  structures.  In  this  section,  we  make  closures  alive  and 
“smart”  by  modifying  them  so  that  they  contain  raw  derivations — a  closure, 
(p,  X,  e)  is  reformatted  into  XA.  p  ©  {x  i->  A}  h  e,  that  is,  a  mapping  from  a 
value.  A,  to  a  sequent  that  uses  A.  Of  course,  the  sequent  is  a  raw  derivation, 
so  we  generalize  the  idea  and  allow  a  closure  to  hold  a  partially  developed 
derivation,  d,  that  is,  AA.  d,  such  that  root{d)  =  p  ©  {x  A}  h  e. 

Using  this  formulation,  we  can  develop  the  bodies  of  closures  and  we  can 
apply  techniques  akin  to  those  from  denotational  semantics  to  reason  about 
the  behavior  of  a  closure  prior  to  its  application. 
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X  ^  Px  p^  ^x.  e  -(1-  A^.  (/>  0  {x  A}  h  e)* 
where  s*  denotes  a  derivation,  d,  such  that  root{d)  =  s  and  isPartial( d) 
p  h  ei  -Ij-  A^.  d  p\-  e2^V2  [v2lA]d  -().  v 


p\-  6x62^  V 

Fig.  5.  Natural  semantics  rule  schemes  for  higher-order  closures 


Let  Pa  =  p  ©  {x  a}  in  the  following; 
p  h  (Ax.x  +  1)2 

/ 

p  h  {Xx.x  +  1) 

XA.  pA  1“  X  -h  1 

>/  \ 

PA^x  pArl  pj 


p  h  (Ax.xH- 1)2 

>/  i  \  "■ 

p  h  (Ax.x  +  1)  pf-2  p2l”X  +  l 


XA.  pA^  xAl 

/  \ 

pAi-X  pA^l 


i  P2^X  P2  H  1  \ 


I  \ 


Fig.  6.  An  example  with  speculative  development 


The  syntax  we  use  goes  as  follows: 


d  G  Derivation 


s  G  Sequent  (p  h  e) 

V  G  Va^ue  (Note:  assume  Sequent  fl  Value  =  0) 
A  G  VariableValue 


p  G  PrimitiveFirstOrderValue  (e.g.,  integer) 
s 

d  ::=  V  I  di  d„,  n  >  0 

V  ::=  p  I  A  I  XA.  d 

This  syntax  is  “higher  order”  in  the  sense  that  derivations  can  contain  values 
that  can  contain  derivations. 

Figure  5  presents  a  set  of  natural  semantics  rule  schemes  for  the  new  form 
of  closures.  The  rule  schemes  in  Figure  5  permit  a  development  to  proceed 
within  a  closure  value;  we  call  this  a  speculative  development.  For  example, 
Figure  6(a)  shows  a  partial  development  of  a  program  where  the  value  part  for 
Ax.  X  -f  1  is  a  closure  that  contains  speculative  development.  This  speeds  up 
the  the  remainder  of  the  development,  because  the  speculative  development 
can  be  used  with  the  substitution  of  2  for  A,  as  seen  in  Figure  6(b);  this 
quickly  leads  to  completion  of  the  derivation,  as  indicated  by  the  two  dotted 
arrows  in  Figure  6(b). 

Of  course,  a  serious  application  of  speculative  development  would  not  limit 
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itself  to  a  strict  left-to-right  strategy;  examples  like  p  h  \x.  (re  +  1)  +  (2  +  3) 
and  p  h  Arc.  if  x  {Xy.  x)  (Xx.  x)  can  benefit  from  a  non-leftmost  speculative 
development. 

Indeed,  partial  evaluation  [5,8]  applied  to  natural  semantics  derivations 
is  aggressive  speculative  development,  and  as  an  ongoing  project,  we  have 
been  applying  partial  evaluation  to  the  variant  of  natural  semantics  seen  in 
this  paper  to  uncover  the  feasibility  of  automated,  static  analysis  of  open 
(“modular”)  programs  [7]. 

6  Applications,  Related  Work,  and  Conclusions 

As  noted  above,  the  modifications  of  natural  semantics  derivations  let  one 
work  easily  with  partial  derivations  and  derivations  of  open  programs  (source 
programs  containing  unbound  variables).  Partial  evaluation  techniques  now 
apply  directly  to  natural  semantics  framework,  as  demonstrated  by  the  on¬ 
going  Ph.D.  research  of  Ibraheem  [7],  where  a  supercompilation  algorithm  by 
Gliick  and  Sprensen  has  been  adapted  to  operate  on  partial  derivations  in 
place  of  so-called  “process  trees”  [5].  This  line  of  research  aims  to  show  that 
static  analysis  of  program  modules  can  be  performed  with  the  same  partial 
evaluation  machinery  used  for  complete  programs. 

Of  course,  the  intuition  that  a  natural  semantics  derivation  can  be  com¬ 
puted  by  a  Prolog  interpreter  is  a  standard  one.  Deransart  and  Ferrand  [4] 
give  a  careful  formulation  of  how  a  goal  tree  can  be  computed  by  a  Pro¬ 
log  interpretater  in  a  left-to-right,  incremental  fashion.  Gunter  and  Remy 
[6]  adapt  Prolog  goal  search  to  natural  semantics  definitions;  they  define  a 
typed  notation,  RAVL,  for  their  presentation  and  show  how  one  might  prove 
a  type-safety  property  in  their  framework.  And  Berry’s  Ph.D.  thesis  describes 
a  suite  of  tools  for  drawing  “animations”  of  the  incremental  generation  of  par¬ 
tial  derivations  [1].  Most  recently,  Stoughton  has  studied  the  formalizaton  of 
partial  generation  of  derivations  within  resumption  semantics  [16]. 

Based  on  the  investigations  in  this  paper,  one  must  conclude  that  the  rela¬ 
tionships  between  big-step,  small-step,  and  denotational  semantics  are  closer, 
in  a  formal  sense,  than  what  has  been  demonstrated  so  far  in  the  literature. 
Although  it  is  premature  to  speculate  exactly  what  class  of  semantic  definition 
is  simultaneously  both  small-step-  and  big-step-like,  it  is  clear  that  there  is  a 
subclass  of  operational  semantics  definitions  that  form  an  intersection  between 
the  two  formats.  And,  the  connections  between  denotational  and  operational 
semantics  need  closer  examination  as  well. 
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Abstract 

We  describe  the  current  state  of  the  design  and  implementation  of  Dops,  a  frame¬ 
work  for  Deterministic  Operational  Semantics  that  will  support  the  incremental 
construction  of  derivation  trees,  starting  from  term/input  pairs.  This  process  of 
derivation  tree  expansion  may  terminate  with  either  a  complete  derivation  tree,  ex¬ 
plaining  why  a  term/input  pair  evaluates  to  a  particular  output,  or  with  a  blocked 
incomplete  derivation  tree,  explaining  why  a  term/input  pair  fails  to  evaluate  to 
an  output;  or  the  process  may  go  on  forever,  yielding,  in  the  limit,  an  infinite  in¬ 
complete  derivation  tree,  explaining  why  a  term/input  pair  fails  to  evaluate  to  an 
output. 

The  Dops  metalanguage  is  a  typed  lambda  calculus  in  which  all  expressions  con¬ 
verge.  Semantic  rules  are  specified  by  lambda  terms  involving  resumptions,  which 
are  used  by  a  rule  to  consume  the  outputs  of  sub-evaluations  and  then  resume  the 
rule’s  work.  A  rule’s  type  describes  the  number  and  kinds  of  sub-evaluations  that 
the  rule  can  initiate,  and  indicates  whether  the  rule  can  block.  The  semantics  of 
Dops  is  defined  in  an  object  language- independent  manner  as  a  small-step  semantics 
on  concrete  derivation  trees:  trees  involving  resumptions.  These  concrete  deriva¬ 
tion  trees  can  then  be  abstracted  into  ordinary  derivation  trees  by  forgetting  the 
resumptions. 


1  The  incremental  construction  of  derivation  trees 

We  begin  by  defining  the  operational  semantics  that  we  will  use  as  an  example 
throughout  the  rest  of  the  paper:  a  big-step,  environment-based  semantics  of 
the  untyped,  call-by-value  lambda  calculus. 
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n  e  Int  a, be  Exp  n  e  Int  a  G  Exp 

Varn  G  Exp  App(a,  b)  G  Exp  Lam(n,  a)  G  Exp 

Fig.  1.  Syntax  of  lambda  expressions 


e  G  Env  n  G  Int  a  G  Exp 
Clos(e,n,  a)  G  Vlu 


Nil()  G  Env 


n  G  Int  X  e  Vlu  e  G  Env 
Cons(n,  X,  e)  G  Env 


Fig.  2.  Values  and  environments 

The  set  Exp  of  lambda  expressions  is  inductively  defined  by  the  rules  of 
Figure  1,  where  Int  is  the  set  of  all  integers.  We  abbreviate 

App(Lam(0,  App(Var  0,  Var  0)),  Lam(0,  App(Var  0,  Var  0))) 

to  {XQ.VQVQ){XQ.VQV(i),  and  make  use  of  similar  abbreviations  (in  which  Vn 
abbreviates  Var  n,  the  nth  variable)  without  further  comment. 

To  define  the  semantics  of  expression  evaluation,  we  need  two  simple  se¬ 
mantic  spaces.  The  sets  Vlu  of  values  and  Env  of  environments  are  defined 
inductively  by  the  rules  of  Figure  2.  For  example,  if  x  and  y  are  values,  then 

e  =  Cons(l,  X,  Cons(3,  y,  Nil( ))) 

is  an  environment:  the  one  in  which  variable  1  has  value  x,  and  variable 
3  has  value  y.  Note  that  e  is  sorted  by  variable  number.  The  functions 
on  environments  that  we  define  will  assume  and  preserve  the  sortedness  of 
environments.  We  also  need  the  familiar  auxiliary  functions  for  looking  up 
the  value  of  an  identifier  in  an  environment  and  updating  an  environment  to 
reflect  a  new  binding: 

Lookup:  Env  — >  Int  — >■  ({( )}  +  Vlu) 

Update:  Env  Int  Vlu  — >•  Env. 

To  understand  the  significance  of  the  sum  in  Lookup’s  type,  consider  the  en¬ 
vironment  e  defined  above.  Then,  Lookup  e  2  is  in(0,  ()),  the  injection  of  the 
empty  tuple  into  the  0th  component  of  the  sum,  since  variable  2  is  not  bound 
in  e.  And  Lookupe  1  is  in(l,  x),  the  injection  of  variable  I’s  value  in  e  into  the 
1st  component  of  the  sum. 

The  semantics  of  expression  evaluation  can  be  defined  as  in  Figure  3,  where 
we  read  “o,  e  x”  as  “expression  a  in  environment  e  evaluates  to  value 
x".  We  consider  the  single  premise  of  the  variable  evaluation  rule  to  be  a 
“side-condition”,  since  it  doesn’t  involve  expression  evaluation.  The  most 
straightforward  way  to  view  this  definition  is  as  the  inductive  definition  of 
the  relation  C  Exp  x  Env  x  Vlu,  where  a,e=^  x  abbreviates  {a,e,x)  G  =^. 
Given  this  interpretation,  we  can  prove  the  following  facts: 

(i)  ^  is  a  partial  function  from  Exp  x  Env  to  Vlu. 
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Lookup  en  =  in(l,a;) 

Varn,  e  x 

Lam(n,  a),e=>  Clos(e,  n,  a) 

a,e  C\os{e',n,a')  b,e^y  a',  Update e' ny  z 
App(a,  b),e=>  z 

Fig.  3.  Definition  of  expression  evaluation 

Ao-UO)  Nil()  =>  a:  Ao-Uq,  Nil()  =»  a;  vo,eo,x  x 

(2)  (3)  (4)  (5)  (6)  (7) 


(1)  (8) 

(where  x  =  Clos(Nil(),0,  Uq)  and  eo,x  =  Cons(0,a;,  Nil( ))) 

Fig.  4.  Complete  derivation 

(ii)  (Ao.Uo)(Ao-t^o),Nil(>  Clos(Nil(),0,uo>- 

(iii)  (Aq.  ui)(Ao.  Vo),  Nil( )  a;  for  no  a;  G  Vlu. 

(iv)  (Aq.  Vo  vo)(Ao.  vo  vo),  Nil( )  a;  for  no  a;  G  Vlu. 

It  is  also  possible  to  think  about  expression  evaluation  more  concretely.  For 
example,  Figure  4  (ignore  the  labels  (l)-(8)  for  now)  consists  of  a  derivation 
tree  proving  (providing  evidence  for)  Fact  (ii).  Since  the  leftmost  and  middle 
children  of  this  tree  are  instances  of  the  axiom  for  abstraction  evaluation,  and 
the  rightmost  child  follows  by  the  variable  rule  (we  omit  the  rule’s  premise, 
since  it’s  a  side-condition),  the  conclusion  follows  by  the  application  rule. 

But,  it  is  also  possible  and  useful  to  think  even  more  concretely,  to  focus 
on  the  step-by-step  procedure  in  which  derivation  trees  are  constructed.  With 
the  tree  of  Figure  4,  we  begin,  in  Step  (1),  with  the  incomplete  derivation 
tree  consisting  of  the  expression/environment  pair  (Aq.  Vo)(Ao.  Vq),  Nil( ).  Next, 
since  our  expression  is  an  application,  we  begin  evaluating  the  left  side  of  the 
application,  in  Step  (2),  and  finish  this  evaluation,  in  Step  (3).  In  Steps  (4) 
and  (5),  we  evaluate  the  right  side  of  the  application.  In  Steps  (6)  and  (7), 
we  evaluate  the  expression  of  the  closure  x  in  the  environment  that  is  formed 
by  binding  the  variable  of  the  closure  in  the  environment  of  the  closure  to 
the  value  of  the  right  side  of  the  application.  Finally,  in  Step  (8),  we  take 
the  result  of  this  rightmost  evaluation  and  make  it  the  result  of  our  overall 
evaluation,  giving  us  a  complete  derivation  providing  evidence  for  Fact  (ii). 

It  is  easy  to  prove  that  the  tree  expansion  procedure  that  we  followed 
above  is  sound  and  complete.  If  we  start  with  an  incomplete  tree  consisting 
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Ao-wi,  Nil()  =5- X  Ao-'yo,  Nil()  y  vi,eo,y^ 
(2)  (3)  (4)  (5)  (6) 


(1) 

(where  x  =  Clos(Nil(),0,Ui),  y  =  Clos(Nil(),  0,uo)  and 
eo,y  =  Cons(0,y,Nil())) 

Fig.  5.  Blocked  incomplete  derivation 


^0  j  ^0,x  ^  ^ 

(7)  (8) 


^0  >  Co, a;  X 

(9)  (10) 


Vq  Vqj  Cq,®  ^ 
(11) 


Aq.  Vo  Vo,  Nil()  =4*  X  Ao.voVo,Nil()  =^x  voVo,eo,x=>- 
(2)  (3)  (4)  (5)  (6) 


(1) 

(where  x  =  Clos(Nil(),0,  UqUo)  and  eo,i  =  Cons(0,  a;,  Nil())) 
Fig.  6.  Infinite  incomplete  derivation 


of  an  expression/environment  pair  a,  e  and  terminate  with  a  complete  tree 
whose  root  is  a,  e  x,  then  a,  e  evaluates  to  x.  And,  if  o,  e  evaluates  to 
X,  then  the  procedure  will  turn  the  incomplete  tree  consisting  of  a,  e  into  a 
complete  tree  with  root  a,e=^  x.  When  the  procedure  doesn’t  terminate  with 
a  complete  derivation  tree,  it  provides  an  explanation  for  why  the  starting 
expression/environment  pair  fails  to  evaluate  to  any  value.  Figure  5  gives  an 
explanation  for  why  Fact  (iii)  holds:  the  procedure  terminates  with  a  blocked 
incomplete  derivation  tree,  since  variable  1  is  not  bound  in  environment  eo,j,. 
And  Figure  6  gives  an  explanation  for  why  Fact  (iv)  holds:  the  procedure  fails 
to  terminate,  giving,  in  the  limit,  an  infinite  incomplete  derivation  tree. 
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sort  Exp  =  Var  of  Int  I  App  of  {Exp,  Exp}  |  Lam  of  {Int,  Exp} 

datatype  Vlu  =  Clos  of  {Env,  Int,  Exp} 

and  Env  =  Nil  of  {}  I  Cons  of  {Int,  Vlu,  Env} 

Fig.  7.  Dops  definitions  of  sorts  and  datatypes 

2  A  framework  for  deterministic  operational  semantics 

We  are  designing  and  implementing  a  framework  for  Deterministic  Opera¬ 
tional  Semantics  called  Dops  that  will  support  the  incremental  construction 
of  derivation  trees,  starting  from  object  language  term/input  pairs.  We  re¬ 
strict  our  attention  to  deterministic  semantics  for  two  reasons.  First,  one  often 
wants  a  semantics  to  be  deterministic,  and  so  it  is  useful  to  have  frameworks  in 
which  expressed  semantics  are  guaranteed  to  be  deterministic.  Second,  to  be 
useful  in  practice,  our  tree  expansion  procedure  itself  will  have  to  be  determin¬ 
istic,  which  means  that  any  nondeterminism  would  have  to  be  reflected  either 
in  the  structure  of  the  derivation  trees  themselves  or  in  a  lack  of  monotonicity 
of  the  tree  expansion  process.  Neither  of  these  alternatives  seems  desirable. 

The  operational  semantics  of  an  object  language  is  expressed  in  the 
Dops  metalanguage,  a  typed  lambda  calculus  with  sums,  products,  alge¬ 
braic  datatypes  (recursive  types  not  directly  involving  function  types)  and 
primitive  recursion.  This  lambda  calculus  only  expresses  total  functions,  i.e., 
all  well-typed  lambda  terms  converge  to  values.  In  the  metalanguage,  n-ary 
sums,  products  and  tuples  are  written  like  [no, . . . , <Tn-i],  {cro,  ■■■, and 
{a:o, . . .  respectively,  so  that  {}  is  the  single  value  of  the  unit  type  {}. 

Much  of  the  metalanguage’s  syntax  is  reminiscent  of  Standard  ML. 

The  syntactic  categories  of  an  object  language  are  defined  as  sorts  in  the 
Dops  metalanguage,  and  each  sort  has  associated  with  it  input  and  output 
types.  Figure  7  shows  how  the  single  sort  Exp  of  our  example  object  lan¬ 
guage,  along  with  its  associated  input  and  output  types,  Env  and  Vlu,  can  be 
expressed  in  our  metalanguage.  Figure  8  shows  how  the  auxiliary  functions 
Lookup  and  Update  can  be  defined  in  the  Dops  metalanguage,  using  primitive 
recursion.  (Straightforward  constraints  are  used  to  prohibit  general  recursion.) 

For  each  constructor  of  a  given  sort  (Var,  Lam  and  App  in  our  example 
object  language),  a  corresponding  semantic  rule  must  be  specified  as  a  meta¬ 
language  term.  When  an  object  language  semantics  would  ordinarily  have 
multiple  inference  rules  for  a  single  constructor,  e.g.,  for  a  conditional  oper¬ 
ator,  the  multiple  rules  will  have  to  be  combined  into  a  single  metalanguage 
term,  in  a  process  that  is  similar  to  the  “left-factoring”  of  [7].  The  rule  corre¬ 
sponding  to  a  constructor  S  of  sort  a  takes  in  an  instance  p  of  the  constructor’s 
data  and  a  value  x  of  cr’s  input  type,  and  describes  how  the  term  5  p  should 
be  evaluated  with  input  x.  This  evaluation  may  cause  various  sub-evaluations 
to  be  initiated,  and  may  eventually  terminate  with  the  production  of  a  value 
of  cr’s  output  type.  Resumptions  are  used  to  consume  the  output  values  of 
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type  VluOpt  =  [{},  Vlu] 

rec  Lookup  :  Env  ->  Int  ->  VluOpt  = 

NilO  =>  fn  _  :  Int  =>  in(0,  VluOpt,  {}) 

I  Cons{l,  u,  e}  =>  fn  n  :  Int  => 

case  n  <  1  of 

True{}  =>  in(0,  VluOpt,  {}) 

I  False{}  => 

case  n  =  1  of 

True{}  =>  u 
I  False{}  =>  Lookup  e  n 
esac 

esac 

rec  Update  :  Env  ->  Int  ->  Vlu  ->  Env  = 

NilO  =>  fn  n  :  Int  =>  fn  v  :  Int  =>  Cons{n,  v,  NilO} 

I  Cons{l,  u,  e}  =>  fn  n  :  Int  =>  fn  v  :  Int  => 

case  n  <  1  of 

TrueO  =>  Cons{n,  v,  ConsO,  u,  e}} 

I  False{}  => 

case  n  =  1  of 

True{}  =>  Cons-Cl,  v,  e} 

I  False{}  =>  Cons{l,  u.  Update  env} 
esac 

esac 


Fig.  8.  Dops  definitions  of  auxiliary  functions 


sub-evaluations  and  then  resume  the  rule’s  work.  The  types  of  rules  involve 
action  types,  which  describe  the  number  and  kinds  of  sub-evaluations  that  an 
application  of  a  rule  is  capable  of  initiating,  and  indicate  whether  an  applica¬ 
tion  of  a  rule  is  capable  of  blocking.  Since  the  metalanguage  is  deterministic, 
and  there  is  only  one  rule  per  constructor,  only  deterministic  semantics  can 
be  expressed  in  Dops. 

Figure  9  shows  how  the  semantic  rules  of  our  example  object  language 
can  be  expressed  in  the  Dops  metalanguage.  Consider  the  most  complex  of 
these  rules:  App.  The  lambda  term  for  App  takes  in  the  left  and  right  sides, 
a  and  b,  of  the  application  to  be  evaluated,  along  with  the  environment  e  in 
which  the  evaluation  should  be  carried  out.  It  then  returns  an  element  of  the 
action  type  App  Act.  Action  types  always  consist  of  sums  with  two  or  more 
components.  Since  the  0th  component  of  AppAct  is  the  empty  type,  we  know 
that  the  evaluation  of  an  application  is  incapable  of  immediately  blocking;  if 
it  had  been  the  unit  type,  then  immediate  blocking  might  have  been  possible. 
And,  since  the  1st  component  of  AppAct  is  also  the  empty  type,  we  know 
that  the  evaluation  of  an  application  cannot  immediately  result  in  a  value  of 
type  Vlu  (the  output  type  of  our  constructor’s  sort);  if  this  component  had 
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type  VaxAct  =  [{},  Vlu] 

rule  Var  :  Int  ->  Env  ->  VarAct  = 

fn  n  :  Int  =>  fn  e  :  Env  =>  Lookup  e  n 

type  AppActS  =  [  []  ,  Vlu] 

type  AppAct2  =  [[]  ,  [],  {Exp,  Env,  Vlu  ->  AppActS}] 

type  AppActl  =  [[],  [],  {Exp,  Env,  Vlu  ->  AppAct2}] 

type  AppAct  =  [[] ,  [],  {Exp,  Env,  Vlu  ->  AppActl}] 

rule  App  :  {Exp,  Exp}  ->  Env  ->  AppAct  = 

fn  {a,  b}  :  {Exp,  Exp}  =>  fn  e  :  Env  => 
in(2,  AppAct, 

{a,  e, 

fn  X  :  Vlu  => 
case  X  of 

Clos{e’,  n,  a’}  => 
in (2,  AppActl, 

{b,  e, 

fn  y  :  Vlu  => 

in (2,  AppAct2, 

{a’.  Update  e’  n  y, 
fn  z  :  Vlu  => 

in(l,  AppActS,  z)})}) 

esac}) 

type  LamAct  =  [ [] ,  Vlu] 

rule  Lam  :  {Int,  Exp}  ->  Env  ->  LamAct  = 

fn  {n,  a}  :  {Int,  Exp}  =>  fn  e  :  Env  => 
in(l,  LamAct,  Clos{e,  n,  a}) 

Fig.  9.  Dops  definitions  of  semantic  rules 

been  Vlu,  then  immediate  production  of  an  output  value  might  have  been 
possible.  Thus  the  value  returned  by  the  application  rule  will  have  to  consist 
of  (the  injection  into  the  2nd  component  of  the  sum  of)  a  triple  with  type 
{Exp,  Env,  Vlu  AppActl}.  The  triple  returned  should  be  thought  of  as  a 
request  to  initiate  a  sub-evaluation:  to  evaluate  the  0th  component  of  the 
triple  with  its  1st  component  as  input,  and  then  to  supply  the  output  value 
produced  by  this  sub-evaluation  to  the  resumption  that  is  the  2nd  component 
of  the  triple.  The  actual  triple  returned  is  thus  a  request  to  evaluate  the  left 
side  a  of  the  application  in  the  environment  e,  and  then  to  call  the  supplied 
resumption  with  the  output  value  x  of  this  sub-evaluation.  The  value  x  must 
be  a  closure,  and  the  resumption  first  gives  names  to  the  components  of  the 
closure,  and  then  initiates  a  second  sub-evaluation:  the  evaluation  of  the  right 
side  b  of  the  application  in  the  environment  e,  where  the  output  value  y  of  the 
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7  G  r+  7  e  r* 

lnit(a,a;)  G  F  - — ; - - - —  1 ; — ;r 

lnc(a,a;,7,/)  G  r  Comp(a,a;,7,2/)  G  F 

Fig.  10.  Concrete  derivation  trees 

sub-evaluation  is  to  be  given  to  the  supplied  resumption.  This  resumption, 
when  invoked,  will  initiate  a  third  and  final  sub-evaluation:  the  evaluation  of 
the  expression  a'  of  the  closure  in  the  environment  that  is  obtained  by  updating 
the  environment  e’  of  the  closure  so  that  the  variable  n  of  the  closure  is  bound 
to  the  value  y  of  6,  where  the  output  value  z  of  this  sub-evaluation  is  to 
be  given  to  the  final  resumption,  which  must  produce  a  value  of  action  type 
AppActS.  Since  AppActS  has  only  two  components,  and  only  its  1st  component 
is  nonempty,  this  resumption  must  yield  (the  injection  into  the  1st  component 
of  AppActS  of)  an  output  value.  The  actual  value  returned  is,  of  course,  z. 

By  examining  the  action  types  VarAct  and  Lam  Act,  we  can  tell  that  eval¬ 
uating  variables  and  lambda  expressions  never  involves  the  initiation  of  sub¬ 
evaluations.  In  particular,  the  side-condition  of  the  variable  evaluation  rule 
is  handled  inside  the  rule.  According  to  VarAct,  variable  evaluation  may  be 
capable  of  blocking,  since  its  0th  component  is  the  unit  type;  and,  if  we  look  at 
the  semantic  rule  for  variable  evaluation,  we  will  see  that  variable  evaluation 
blocks  when  a  variable  is  looked  up  in  an  environment  where  it  is  unbound. 
On  the  other  hand,  Lam  Act  tells  us  that  lambda  expression  evaluation  always 
terminates  normally. 

The  semantics  of  Dops  is  defined  in  an  object  language-independent  man¬ 
ner  via  a  small-step  semantics  on  the  set  F  of  concrete  derivation  trees,  which 
are  inductively  defined  in  Figure  10.  In  this  figure,  F*  denotes  the  set  of  all 
tuples  of  elements  of  F,  and  F"'"  denotes  the  set  of  all  nonempty  tuples  of 
elements  of  F.  When  evaluating  a  term  a  with  input  x,  one  starts  with  the 
initial  concrete  derivation  tree  lnit(o,a;).  After  some  number  of  tree  expan¬ 
sion  steps,  one  may  have  an  incomplete  concrete  derivation  tree  of  the  form 
lnc(a,  a:,7, /).  Here  the  elements  of  7  are  the  sub-derivations  that  have  been 
constructed  so  far  during  the  evaluation,  and  the  resumption  /  is  waiting  for 
the  last  sub-derivation  of  7  to  become  complete;  then  the  output  value  of 
this  sub-derivation  will  be  supplied  to  the  resumption.  Eventually,  the  tree 
expansion  process  may  terminate  with  a  complete  concrete  derivation  tree  of 
the  form  Comp(a,a;,  7,y).  Here,  y  is  the  output  value  obtained  after  evalu¬ 
ating  a  with  input  x,  and  7  would  only  be  the  empty  tuple  if  the  complete 
derivation  tree  was  formed  directly  from  lnit(a,a:).  There  is  a  typing  system 
for  concrete  derivation  trees  that  puts  some  additional  constraints  on  these 
trees,  requiring  the  types  of  their  components  to  be  compatible  and  requiring 
all  non-final  sub-derivations  to  be  complete. 

The  tree  expansion  relation  — >  C  F  x  F  is  inductively  defined  by  Figure  11, 
where  i  >  0,  Jj.  is  the  metalanguage  evaluation  relation,  rule^  denotes  the  rule  (a 
metalanguage  term)  corresponding  to  the  constructor  6,  and  @  appends  tuples. 
Note  that  the  premises  of  the  first  four  rules  don’t  involve  tree  expansion  and 
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rule^po:  JJ-  in(l,o-,y) 
lnit(5p,x)  ->  Comp(5p,a;,  (),y) 

rule^pa;  -IJ-  in(z  +  2,  cr,  {a,  y,  /}) 
lnit(5p,a;)  ->  lnc(5p,a;,  (lnit(a,p)),/) 

_ /  z -il-  in(l,  g,  w) _ 

lnc(a,a;,7i  @  (Comp(6,y,72,^)),/) 

Comp(a,  X,  7i  @  (Comp(6,  y,  72,  z)),  w) 

_ / -2  in(i  +  2,  g,  {c,tt;,y}) _ 

lnc(a,a;,7i  @  (Comp(&,y,72,2:)),/>  ^ 

Comp(a,  X,  7i  @  (Comp(6,  y,  72, 2),  lnit(c,  w)),9) 

_ 7i  72 _ 

lnc(5p,x,7@  (71),/)  ^  lnc(5p,a;,7@  (72),/) 

Fig.  11.  Definition  of  tree  expansion  relation 
so  can  be  viewed  as  side-conditions. 

The  first  two  tree  expansion  rules  show  how  an  initial  concrete  derivation 
tree  lnit(5p,a;)  is  expanded.  We  proceed  by  taking  the  rule  corresponding  to 
the  constructor  5  and  applying  it  to  the  constructor’s  data  p  and  the  input 
value  X.  If  our  derivation  tree  is  well-typed,  this  will  result  in  a  value  of  the 
action  type  g  of  (5’s  rule  (metalanguage  non-termination  is  not  possible).  If 
the  action  type  allows  for  immediate  blocking,  then  the  resulting  value  may 
have  the  form  in(0,g,  {}),  which  means  that  object  language  blocking  will 
occur.  Otherwise,  there  are  two  possibilities.  The  resulting  value  may  have 
the  form  in(l,g,y),  which  means  that  the  rule  has  immediately  produced 
the  output  value  y,  in  which  case  our  derivation  tree  must  be  turned  into 
a  complete  concrete  derivation  tree  with  output  y.  On  the  other  hand,  the 
value  may  have  the  form  in(i  +  2,  g,  {a,  y,  /}),  which  is  a  request  to  initiate  a 
sub-evaluation.  In  this  case,  our  derivation  tree  is  turned  into  the  incomplete 
concrete  derivation  tree 

lnc(Jp,a;,  (lnit(a,y)),/), 

in  which  the  sub-evaluation  of  term  a  with  input  y  has  been  initiated,  and  the 
resumption  /  is  waiting  for  the  sub-derivation  lnit(o,  y)  to  become  complete. 

The  next  two  tree  expansion  rules  are  similar,  but  are  concerned  with  the 
expansion  of  incomplete  concrete  derivation  trees  whose  last  sub-derivations 
have  become  complete.  Again,  object  language  blocking  is  only  possible  if 
allowed  by  the  action  type  g  of  the  metalanguage  term  that  is  being  evaluated. 
Finally,  the  last  rule  is  a  contextual  rule:  it  shows  how  the  last  sub-derivation 
of  an  incomplete  concrete  derivation  tree  can  be  expanded  in  place. 
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There  is  one  more  aspect  to  the  semantics  of  Dops:  the  translation  of  con¬ 
crete  derivation  trees  into  abstract  derivation  trees.  Abstract  derivation  trees 
are  defined  as  certain  functions  from  tree  paths  to  tree  nodes  consisting  of 
either  term/input  pairs  a,  x  or  output  values  y.  Then,  a  tree  abstraction  func¬ 
tion  abs  can  be  defined  in  such  a  way  that  7-^7'  implies  that  abs7  C  abs7'. 
Resumptions  are  discarded  as  part  of  the  abstraction  process.  Then,  the 
meaning  of  a  term/input  pair  a,  x  can  be  defined  to  be  the  abstract  derivation 
tree 

abs 7  I  lnit(a,  x)  — >*  7}. 

The  meaning  of  a  term/input  pair  will  be  a  complete  (and  finite)  derivation 
tree  like  the  tree  of  Figure  4,  or  a  blocked  incomplete  derivation  tree  like 
the  one  of  Figure  5,  or  an  infinite  incomplete  derivation  tree  like  the  one  of 
Figure  6. 

The  implementation  of  Dops  will  allow  users  to  construct  as  much  of  the 
meanings  of  term/input  pairs  as  they  desire.  At  each  point  in  the  evaluation 
of  a  given  term/input  pair,  the  user  will  be  presented  with  a  single  node 
of  the  abstraction  of  the  current  concrete  derivation  tree,  since  the  whole 
abstract  derivation  tree  will  typically  be  far  too  large  to  display  in  its  entirety. 
The  user  will  be  able  to  navigate  around  the  abstract  derivation  tree,  and 
to  view  as  much  of  the  metalanguage  values  occurring  in  the  tree’s  nodes  as 
they  wish  (these  values  may  themselves  become  too  large  to  display  fully). 
They  may  also  opt  to  view  the  resumptions  that  occur  in  the  underlying 
concrete  derivation  tree,  which  will  normally  be  hidden.  There  will  be  various 
commands  for  continuing  the  tree  expansion  process,  causing  more  of  the  final 
meaning  to  be  constructed. 

Dops  specifications  of  the  following  operational  semantics  have  been  writ¬ 
ten:  a  typing  system  for  the  simply  typed  lambda  calculus,  substitution-based, 
big-  and  small-step  semantics  for  the  call-by-value  untyped  lambda-calculus, 
and  big-  and  small-step  semantics  for  a  simple  imperative  language.  When 
expressing  a  small-step  semantics  in  Dops,  one  will  make  use  of  output  types 
involving  terms.  It  is  also  useful  to  add  an  extra  layer  to  a  small-step  seman¬ 
tics  that  computes  the  transitive  closure  of  the  original  small-step  relation. 
Dops  is  currently  being  implemented  in  Standard  ML. 

3  Comparison  with  related  work 

There  are  various  operational  semantics  (or  logical)  frameworks  that  allow 
users  to  evaluate  object  language  term/input  pairs  [2,1,6, 7,4].  Some  of  these 
frameworks  support  the  construction  of  complete  derivation  trees  in  cases 
when  term/input  pairs  evaluate  to  output  values  [1,6,4].  But,  as  far  as  I  know, 
only  D.  Berry’s  Animator  Generator  [1]  supports  the  incremental  construction 
of  derivation  trees. 

The  Animator  Generator  takes  in  a  deterministic  operational  semantics  for 
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a  programming  language  and  generates  an  animator  for  that  language.  The 
animator  incrementally  constructs  derivation  trees,  starting  from  term/input 
pairs,  and  displays  various  views  of  those  trees.  One  of  these  views,  which 
Berry  calls  a  “semantic  view” ,  displays  whole  derivation  trees.  From  our  point 
of  view,  however,  the  Animator  Generator  suffers  from  several  deficiencies. 

The  Animator  Generator  doesn’t  do  a  good  job  of  displaying  derivation 
trees  (supporting  other  kinds  of  views  had  much  higher  priority).  The  main 
problem  is  that  it  insists  on  displaying  an  entire  derivation  tree  in  a  single 
window;  when  the  tree  becomes  large,  this  makes  it  very  difficult  to  navigate 
around  the  tree.  The  problem  is  compounded  by  the  fact  that  semantic  values 
are  also  displayed  in  their  entirety.  We  hope  that  our  approach  to  displaying 
derivation  trees  will  work  better  in  practice. 

In  the  Animator  Generator’s  metalanguage,  auxiliary  tests  and  functions 
must  be  expressed  as  separate  sets  of  rules.  Unfortunately,  this  means  that 
the  side-conditions  and  auxiliary  operations  of  rules  may  fail  to  be  total  (i.e., 
may  diverge),  which  can  lead  to  apparent  rule  blocking  that  won’t  be  detected 
by  the  system.  This  deficiency  is  shared  by  all  of  the  frameworks  referred  to 
above,  but  is  avoided  in  Dops  by  employing  a  metalanguage  in  which  all  terms 
converge. 

Finally,  the  tree  expansion  model  of  the  Animator  Generator  is  much  more 
complicated  than  our  definition  of  tree  expansion  (Figure  11)  via  a  small-step 
semantics  on  concrete  derivation  trees. 

The  incremental  construction  of  derivation  trees  has  also  been  advocated 
by  Gunter  and  Remy  [3].  They  gave  a  definition  of  “partial  proofs”  in  the  con¬ 
text  of  a  big-step  semantics  of  a  simple  programming  language.  However,  they 
only  gave  an  informal  description  of  how  one  partial  proof  can  be  transformed 
into  another,  by  “resolving  or  extending  subgoals”  in  the  first. 
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Abstract 

This  article  describes  how  the  use  of  a  higher-order  syntax  representation  of  contexts 
[due  to  A.  Pitts]  combines  smoothly  with  higher-order  syntax  for  evaluation  rules,  so 
that  definitions  can  be  extended  to  work  over  contexts.  This  provides  ’’for  free”  — 
without  the  development  of  any  new  language-specific  context  calculi  —  evaluation 
rules  for  contexts  which  commute  with  hole-filling.  We  have  found  this  to  be  a  useful 
technique  for  directly  reasoning  about  operational  equivalence.  A  small  illustration 
is  given  based  on  a  unique  fixed-point  induction  principle  for  a  notion  of  guarded 
context  in  a  functional  language. 


1  About  contexts 

The  notion  of  a  context  is  widely  used  in  programming  language  semantics  — 
for  example  in  the  definition  of  operational  equivalences,  or  program  transfor¬ 
mation,  and  in  certain  styles  of  operational  semantics  definitions. 

A  context  is  just  a  term  with  some  holes.  The  holes  are  place-holders  for 
missing  subterms.  Each  hole  may  occur  zero  or  more  times,  and  the  process  of 
filling  a  hole  with  a  term  is  the  textual  operation  of  replacing  all  occurrences 
of  a  hole  by  the  corresponding  term.  For  most  of  this  article  we  will  consider 
contexts  with  just  one  hole,  and  that  hole  may  occur  zero  or  more  times  in 
the  context. 

The  difference  between  hole-filling  and  the  usual  notion  of  substitution 
arises  when  the  language  contains  binding  operators;  filling  a  hole  with  a 
term  may  cause  variable  in  the  term  to  be  bound. 

For  example,  the  lambda-calculus  context  (Ax.[  ])Aa:.Ay.[  ]  is  a  context  with 
one  hole,  written  [  ],  and  this  hole  occurs  twice.  Call  this  context  C.  Filling 
the  hole  in  C  with  the  term  x  y,  which  is  typically  denoted  by  C[x  y],  results 
in  the  term  (Aa;.x  y)Xx.Xy.x  y.  Note  that  the  resulting  term  has  one  free 
occurrence  of  the  variable  y,  and  that  the  variable  x  has  been  captured  —  in 
this  example  by  two  different  lambda  abstractions.  Because  of  this  possibility 
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of  variable-capture  (even  in  the  case  when  a  hole  occurs  just  once  in  a  term), 
such  contexts  cannot  be  identified  up  to  renaming  of  bound  variables,  since 
renaming  does  not  “commute  with  hole  filling” .  In  this  example: 

fill  with  xy 

(Aa:.[])Ax.Ay.[] - ^[Xx.x  y)\x.Xy.x  y 

a-convert 

1  ,  fill  with  X  y  .  X  J  X 

(Az.[])Ax.A?/.[] - ^(A^j.a;  y)Xx.Xy.x  y 

Note  that  the  terms  of  the  right-hand  side  are  not  a-convertible.  Such  prob¬ 
lems  arise  when  one  attempts  to  argue  properties  about  the  behaviour  of 
“terms-in-context” .  For  example,  in  direct  proofs  about  contextual  equiva¬ 
lence. 


Representations  of  Contexts:  Previous  work 


Talcott  and  Mason  et  al  [MT91,AMST97,Tal97]  present  some  direct  proofs 
about  contextual  equivalence  in  a  lambda  calculus  with  effects.  In  order  to 
be  made  rigorous,  these  arguments  require  the  development  of  a  calculus  of 
generalised  contexts.  This  development  is  based  on  Talcott’s  earlier  work  on  a 
theory  of  binding  structures  [Tal92,Tal93];  related  work  is  reported  by  Mason 
[Mas96]. 

The  Talcott/Mason  approach  takes  the  following  form.  For  the  particular 
term  language  under  study  one  must 

(i)  introduce  a  generalised  definition  of  contexts  where  holes  are  decorated 
with  (generalised)  substitutions; 

(ii)  establish  basic  definitions  for  generalised  contexts,  such  as  substitution 
and  hole-filling; 

(iii)  lift  the  definition  of  computation  (reduction)  up  to  generalised  contexts 

(iv)  establish  the  main  result:  that  reduction  “commutes  with  hole  filling” 

One  can  motivate  the  Talcott/Mason  representation  of  contexts  by  considering 
the  last  point:  the  problem  of  extending  the  definition  of  reduction  to  work 
on  contexts  in  such  a  way  that  it  commutes  with  hole-filling.  Consider  the 
lambda-calculus  context  (Aa:[  ])/  (where  I  is  the  identity  function,  Xx.x).  If 
one  extended  /3-reduction  naively  to  contexts  we  would  obtain: 

(Aa;[  ])/  [  ] 

This  is  clearly  not  adequate,  since  e.g.  filling  the  hole  with  x  does  not  “com¬ 
mute”  with  this  reduction: 


(Aa:.[])/- 

fill  with  X 

{Xx.x)I- 


i[] 


fill  with  X 


■J  ^  X 


The  problem  here  is  that  the  reduction  step  “forgets”  the  term  I.  The  solution 
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is  to  decorate  holes  with  explicit  substitutions,  so  that  e.g., 

But  once  this  extension  is  made,  the  range  of  substitutions  must  also  be  per¬ 
mitted  to  contain  generalised  contexts,  so  that  e.g., 

(Ay.l  ])[  1 1'^ '  where  0  =  fe] 


Summary 

In  this  note  we  show  how  an  alternative  approach  to  representing  contexts 
significantly  simplifies,  and  to  some  extent  generalises  the  “context  calculus” 
that  is  required  to  compute  with  contexts. 

•  The  first  simplification  is  that  the  representation  of  contexts  —  which  is 
due  to  Pitts  [Pit94]  —  is  based  on  higher-order  syntax  (i.e.  typed  lambda- 
calculus  as  a  syntactic  meta-language),  so  no  new  calculus  needs  to  be 
developed; 

•  The  second  simplification  is  that  we  show  how  many  common  definitions 
involving  terms,  e.g.,  evaluation  relations,  reduction,  abstract-machine  steps 
and  sets  of  terms  or  contexts  specified  by  grammars,  can  be  “automatically” 
extended  to  contexts  in  such  a  way  that  they  commute  with  hole-filling  “for 
free”. 

•  It  generalises  previous  approaches  in  the  sense  that  it  is  not  tied  to  a  par¬ 
ticular  syntax  or  a  particular  relation  involving  terms  (i.e.  reduction). 

The  author  has  already  made  extensive  use  of  these  techniques  in  a  number 
of  proofs  about  operational  semantics;  the  initial  motivations  for  this  work 
were  the  proofs  about  the  GDSOS  operational  semantics  rule-format  presented 
in  [San97].  The  proofs^  of  many  of  the  results  reported  there  build  on  the 
ideas  presented  in  this  note. 

There  are  a  few  alternative  context-calculi  that  have  appeared  in  the 
literature.  Lee  and  Friedman  [LF96]  propose  a  calculus  in  which  contexts 
are  regarded  as  concrete  representations  (source  code)  for  terms.  More  re¬ 
cently,  Hashimoto  and  Ohori  [H098]  describe  a  context  calculus  which  ex¬ 
tends  lambda  calculus  to  include  first-class  contexts  (via  context  abstraction 
and  context  application  (=  hole-filling).  Their  main  result  is  that  the  calcu¬ 
lus  is  confluent,  and  this  is  achieved  with  the  help  of  a  type  system.  Their 
calculus  involves  labelling  hole  variables  with  renamings,  which  is  reminicent 
of  Talcott’s  approach. 

The  remainder  of  this  note  is  organised  as  follows:  In  section  2  we  introduce 
Pitts’  representation  of  contexts.  In  section  3  we  show  how  this  representa¬ 
tion  combines  smoothly  with  the  use  of  higher-order  syntax  in  term-based 
definitions  (e.g.  operational  semantics  rules),  so  that  definitions  extend  to 


^  Due  to  space  limitations,  these  proofs  do  not  appear  in  the  conference  article 
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contexts  “for  free” .  By  way  of  illustration,  in  the  concluding  section  we  look 
at  a  small  application  of  the  ideas  to  the  proof  of  a  unique  fixed-point  theo¬ 
rem  (in  the  style  of  guarded-recursion  theorems  in  process  calculus)  for  a  lazy 
lambda-calculus  with  constructors. 


2  A  Second-order  Representation  of  Contexts 

The  definition  of  contexts  which  we  adopt  here  was  introduced  by  Pitts  in 
[Pit94].  Pitts’  main  motivation  for  adopting  a  non-standard  definition  of 
contexts  appears  to  be  that  standard  contexts  cannot  be  identified  up  to  a- 
equi  valence. 

Pitts  solves  this  problem  by  using  function  variables  to  represent  holes, 
and  to  represent  hole  filling  by  substitution  of  meta-abstractions  for  these 
function  variables.  This  representation  does  indeed  enable  contexts  to  be 
identified  up  to  renaming  of  bound  variables;  the  key  point  of  this  note  is  that 
the  representation  allows  hole-filling  to  “commute”  with  many  other  relations 
involving  terms,  not  just  a-equi valence. 

The  basic  idea  can  be  illustrated  by  some  examples.  A  hole  will  be  repre¬ 
sented  by  an  application  of  some  function- variable  ^  to  a  vector  of  variables. 
Each  function  variable  has  a  given  arity,  which  dictates  exactly  how  many 
arguments  it  expects.  For  example,  the  conventional  context  (Aa;[  ])/  could  be 
represented  by  {Xx.^{x))I  (so  in  this  case  ^  has  arity  1).  This  representation 
of  the  context  can  be  a-converted  in  the  usual  way.  Hole-filling  is  represented 
by  substituting  a  meta- abstraction  for  Filling  (Aa:[  ])/  with  x  will  now  be 
represented  by  applying  the  substitution  [(^)^/^] 

{(Ax.f(x))/)(W*/^]  =  ((A!,.f(!/))/)|(^)V«l 
=  {iXy.ix)x  •  (y))/) 

=  ((Ay.y)/) 

In  the  second  line  we  have  informally  written  a  meta-syntactic  application 
{x)x  •  (y)  to  represent  the  application  of  the  abstraction  {x)x  to  the  variable 
y  is  reduced  to  y.  Since  we  only  need  second-order  function- variables  (i.e., 
function  variables  which  range  over  abstractions  of  terms)  these  meta-beta- 
reductions  can  be  incorporated  into  the  definition  of  substitution  itself. 

Notice  also  with  this  example  that  we  can  now  ^S-reduce  the  context: 

((Ai.e(i))/)  {(/) 

and  now  we  get  ^(f)[(^)^/c]  =  /  as  we  hoped.  As  we  shall  see  in  the  next 
section,  the  fact  that  this  works  boils  down  to  a  simple  associativity  property 
of  substitutions  (the  standard  lambda-calculus  substitution  lemma). 
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Term  Syntax 

In  the  general  definitions  which  follow  we  will  adopt  a  type-theory-style 
abstract  syntax  for  terms  (see  e.g.  [HL78,MN95,NPS90,PE88]).  For  specific 
examples  we  will  use  the  familiar  terms  from  the  lambda-calculus,  and  their 
usual  concrete  syntax. 

First  we  fix  a  countably  infinite  set  Var  of  ordinary  variables.  A  language  L 
is  specified  by  a  set  of  operators  O  of  a  fixed  arity.  As  usual,  the  arity  specifies 
the  number  of  operands  for  each  operator,  but  it  specifies  more  than  just  this, 
since  we  wish  to  specify  the  syntax  of  operators  with  binding.  Each  operand 
is  possibly  an  abstraction,  i.e.,  a  list  of  zero  or  more  distinct  variables  followed 
by  a  term,  where  the  variables  are  considered  bound  in  the  term.  The  arity 
of  an  operator  is  therefore  given  by  a  sequence  of  natural  numbers;  the  length 
of  the  sequence  is  the  number  of  operands,  and  the  natural  numbers  are  the 
number  of  bound  variables  associated  with  the  corresponding  operand.  For 
example,  the  terms  of  the  lambda  calculus  would  be  represented  in  this  syntax 
by  the  set  of  operators  {A,  apply}  with  arity(A)  =  (1),  arity(app/y)  =  (0,0). 

Let  X,  y,  etc.,  range  over  For,  and  let  p,  q  range  over  O. 

The  terms  of  L,  T,  ranged  over  by  M,  N  are  defined  inductively  as  follows: 


xeT 


Ml  gr---Mn  gr 
p(  (xi)Mi, . . . ,  {xn)M„)  e  T 


arity  (p)  =  {h, 


each  Xi  is  a  list  of  ki  distinct  variables. 


•  •  kn) 


For  example,  the  term  {Xx.y)z  would  be  written  in  this  abstract  syntax  as 
apply  {\{{x)y),z). 


Contexts 

Now  we  can  be  more  precise  about  the  definition  of  contexts.  We  follow 
[Pit94]  quite  closely,  albeit  with  a  more  general  term-syntax,  (but  a  more 
casual  treatment  of  free  variables). 

Contexts  are  an  extension  of  terms  to  include  hole-variables.  Fix  a  count¬ 
ably  infinite  set  HVar  of  hole  variables.  Each  hole  variable  has  an  associated 
arity  (which  we  will  also  denote  arity  (^))  which  is  a  natural  number.  Hole 
variables  of  arity  n  will  range  over  abstractions  of  the  form:  (xi, . . . ,  x„)M. 

The  contexts  T*,  ranged  over  by  C,  D,  C  etc  are  defined  inductively  as 
follows: 


X  6  T* 


Cl  gT*---Q  er* 
C(Ci,...,C„)6T* 


arity(^)  =  n 


Cl  gT*---C„  gr* 
p((^i)Ci,---,(^n)C„)  e  T* 


arity(p)  =  (A:i, . . .  A:„) 


each  Xi  is  a  list  of  ki  distinct  variables. 
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Hole  Filling 

Hole  filling  is  defined  by  substitution.  The  usual  definition  of  substitu¬ 
tion  of  terms  for  variables  is  routinely  extended  to  substitution  of  contexts 
for  variables.  We  use  the  notation  to  denote  the  result  of  simulta¬ 

neous  substitution  of  contexts  C  =  Ci , . . . ,  Cn  for  some  distinct  variables 

X  =  Xi,...,Xn. 

Substitution  in  the  case  of  hole  variables  requires  a  little  more  attention.  If 
^  is  a  hole  variable  of  arity  fc,  then  we  need  to  define  the  result  of  substituting 
a  meta-abstraction  of  the  form  (xi, . . . ,  Xit)©  for  occurrences  of  ^  in  a  context 
C. 

The  definition  of  substitution  is  much  as  one  would  expect,  inductively 
following  the  term-structure,  and  avoiding  free- variable  capture  along  the  way. 
The  interesting  case  is  the  following: 

J(Ci, . . . ,  ■  ■  ■ .  =  D[C'/j] 

where  C  =  ■  ■  ■  ’ 

This  step  can  be  (informally)  broken  down  into  two  stages, 

(i)  the  substitution  of  (x)D  for  ^  to  yield 

(ii)  the  meta-/?-reduction  of  the  application  to  give 

Of  course  this  is  only  informal,  since  the  meta-application  which  appears  after 
step  1  is  not  part  of  the  syntax. 

About  substitution 

Something  which  should  be  borne  in  mind  when  considering  the  presenta¬ 
tion  of  syntax  that  we  are  using  is  that  it  is  really  just  a  fragment  of  a  simply 
typed  lambda-calculus.  There  is  just  one  base-type,  o,  representing  the  type 
of  terms.  An  operator  of  arity  e.g.,  (0,2)  can  be  thought  of  as  a  constant 
of  type  (o  X  ((o  x  o)  — ^  o))  ->•  o.  An  ordinary  variable  has  type  o,  and  a 
hole-variable  of  arity  n  can  be  thought  of  as  having  type 

(o  X  •  •  •  X  o)  ->  o 

' - V - ' 

n 

Thinking  of  our  syntax  as  a  typed  lambda  calculus  one  should  note  that 
we  only  consider  terms  which  are  head-normal  forms.  One  could  add  meta¬ 
application  and  projections  to  the  syntax  to  obtain  a  more  complete  syntactic 
metalanguage  (as  in  Martin-Lof’s  theory  of  arities  [NPS90])  although  we  do 
not  consider  this  necessary  for  present  purposes. 

It  should  now  be  no  surprise  that  certain  standard  results  from  the  lambda- 
calculus  carry  over  to  contexts.  We  mention  one  such  result  which  will  be 
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useful  in  the  next  section:  a  cut-down  version  of  the  substitution  lemma,  which 
states  a  commutativity  property  of  substitutions: 


Lemma  2.1  (Substitution  Lemma)  Ify^FV(B)\x  then 


Representing  conventional  contexts 

If  we  are  to  use  this  alternative  -  and  more  general  -  representation  of 
contexts  in  order  to  facilitate  reasoning  about  e.g.  contextual  (operational) 
equivalence,  then  it  is  important  to  understand  the  connection  to  the  conven¬ 
tional  notion  of  context. 

Conventional  contexts  correspond  to  a  strict  subset  of  contexts  —  namely 
those  in  which  all  occurrences  of  a  hole  variable  ^  occur  as  ^{x)  for  some 
distinct  variables  x. 

For  a  conventional  context  C  containing  zero  or  more  occurrences  of  a  hole 
[  ],  let  traps{C)  denote  the  set  of  the  variables  which  are  in  scope  at  at  least 
one  occurrence  of  the  hole  in  C  -  i.e.  the  set  of  variables  which  may  become 
trapped  (captured)  at  some  occurrences  when  the  hole  is  filled.  So  for  example 
traps{{Xx.[  ])(Ay.[  ]))  =  {x,y}.  Let  traps{C)  denote  some  canonical  vector  of 
the  trapped  variables  (e.g.,  listed  from  left-to-right  according  to  the  bindings 
in  C). 

For  each  context  C,  we  inductively  define  the  mapping  (•)£  which  takes 
a  conventional  context  to  a  generalised  context  by  replacing  holes  with  the 
context  C: 

{x)c  =  X 

{p{  {Xx)Ci,  {Xn)Cn))c  =  p{  (^l)(C'l)c,  •  •  •  ,  (^n)(C'n)c) 

([]>c  =  C 

In  other  words,  mixing  the  conventional  and  general  context  notations  we 
could  say  that  {C)c  =  C'[C]- 

A  conventional  context  C  can  be  represented  by  ((7)^(2),  where  x  are  the 
captured  variables  of  C.  Then  the  operation  of  filling  C  with  the  term  M 
is  represented  by  the  substitution  [(^)-^/^].  The  following  lemma  makes  this 
claim  precise: 

Lemma  2.2  For  any  conventional  context  C,  and  any  term  M,  if  traps{C)  = 
X  and  ^  is  any  hole  variable  of  arity  |x|,  then 

C[M]  =  (C)e(2)[(^)^/^] 

The  proof  is  by  induction  on  the  structure  of  C. 

The  extended  definition  of  contexts  (henceforth  called  simply  contexts) 
subsume  conventional  contexts;  conventional  contexts  correspond  to  contexts 
with  one  hole  variable,  and  for  which  all  occurrences  are  identically  of  the 
form  ^(x)  for  some  vector  of  distinct  variables  x. 
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3  Extending  Definitions  from  Terms  to  Contexts 

The  purpose  of  this  section  is  to  show  how  typical  syntax-oriented  definitions 
can  be  lifted  to  operate  over  contexts  in  a  natural  way. 

We  proceed  by  considering  a  tiny  example:  an  evaluation  relation  for  the 
lazy  lambda  calculus. 

M\^Xx.M' 

MNi^N' 


Xx.Mij^Xx.M 

We  would  like  to  lift  this  definition  to  contexts  in  the  following  obvious 
way: 

qiAx.C 

CD.II-ID)' 

Aa:.aj.Aa:.C 

What  is  more,  for  this  definition  to  be  useful  we  would  like  to  be  sure  that 
hole-filling  and  the  evaluation  relation  commute.  We  could  just  knuckle  down 
and  prove  this,  but  the  point  we  wish  to  make  in  this  section  is  that  this  will 
always  work  for  syntax  oriented  definitions,  by  virtue  of  the  representation  of 
contexts.  To  see  why  this  is  so,  we  will  need  to  be  more  formal  about  the  rules 
which  make  up  such  inductive  definitions. 


Formal  rules 

In  order  give  a  precise  meaning  of  rules  such  as  those  above  we  switch  to  the 
second-order  syntax  for  terms  and  introduce  a  syntax  for  meta  terms.  For  the 
terms  of  a  given  language,  fix  a  countable  set  of  metavariables  Mvar  ranged 
over  hy  X,y,  etc.  Metavariables  will  range  over  both  terms  and  abstractions 
of  terms,  and  will  be  used  to  formalise  rules  such  as  those  above.  Metavariables 
will  be  assumed  disjoint  from  hole  variables  and  ordinary  variables.  Just  as 
for  hole  variables,  with  each  metavariable  X,  we  associate  an  arity  which  is 
a  natural  number.  The  idea  is  that  metavariables  of  arity  0  will  range  over 
terms,  while  meta  variables  of  higher  arity  will  range  over  abstractions.  Value 
metavariables  always  have  arity  0. 

Definition  3.1  To  define  the  meta-terms  for  a  given  language  we  define  an 
indexed  set  of  meta-abstractions  {MTi}^^Q,  (ranged  over  by  Ai,  M,  etc.). 
MTq  are  the  meta-terms  proper,  used  to  denote  terms  in  formal  definitions. 
For  each  k  >  0,  MTk  is  the  set  of  meta-terms  which  represent  k-variable 
abstractions  of  terms.  The  raw  syntax  of  meta-terms  follows  the  syntax  of 
terms,  with  the  exception  of  a  meta-application  operator,  which  appears  in  the 
form  X  •  {M-i, . . . ,  M-n) •  These  sets  are  given  inductively  by  the  following 
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rules: 


X  e  MTo 

XeMTn 

Me  MTo 

(^1  7  •  •  -  j 

,)M  e  MTn 

G  MTq  • 

■•■Mn  e  MTo 

X-{Mi,... 

,  Mn)  G  MTq 

Ml  e  MTk, . 

..Mne  MTk^ 

arity(A')  =  n 


arity(Af)  =  n 


p{Mu...,Mn)  €  MTo 
One  can  easily  see  that  meta-terms  include  the  terms  of  the  language.  Meta¬ 
terms  are  used  to  formalise  syntax-oriented  definitions.  The  rules  above  can 
be  formalised  as: 


X^XXi  Xi-(y)i}.Z 
apply  {X.y^Z 


XXi\l.XXi 

A  raw  instance  of  a  rule  is  obtained  by  applying  a  substitution  to  the 
metavariables  in  a  rule.  A  substitution  replaces  metavariables  by  term-abstractions 
of  the  corresponding  arity.  For  example,  the  substitution  a  = 
applied  to  the  rule-schema  (which  incidentally  has  zero  premises)  AA'iJj.AA’i 
gives  A(a;)xa:JJ.A(a;)xx  The  valid  instances  (usually  just  called  rule-instances) 
are  defined  inductively  in  the  obvious  way  as  a  the  raw  instances  for  which 
each  premise  is  a  conclusions  for  some  valid  instance.  There  may  be  other 
side-conditions,  e.g.,  that  all  instances  involve  only  closed  terms. 


Extending  Instances  to  Contexts 

Any  collection  of  rule  schemas  can  thus  be  viewed  as  inductively  gener¬ 
ating  certain  sets.  Lifting  these  definitions  to  contexts  is  now  trivial:  simply 
allow  the  instances  of  a  rule  to  contain  hole  variables.  In  other  words  we  al¬ 
low  substitution  instances  of  a  rule  to  replace  metavariables  by  contexts  (or 
abstractions  of  contexts) .  We  will  call  such  an  instance  a  context  rule  instance. 

Let  us  consider  a  concrete  example.  Given  the  formal  rule  for  beta- 
reduction: 

ixxi)y  A'l  •  CF) 

where  for  the  sake  of  readability  we  have  written  application  in  the  usual 
implicit  form,  we  can  construct  a  rule  instance  by  applying  the  substitution 
[(a;)^(a:),  which  gives: 

{X{x)^{x))  ^{x)  ^(C(x)) 


9 


Generalising  “evaluation/reduction  commutes  with  hole  filling” 

The  generalisation  of  the  idea  that  “evaluation/reduction  commutes  with 
hole  filling”  is  that  filling  the  holes  in  a  valid  rule-instance  yields  a  valid  rule 
instance. 

Theorem  3.2  Let  ^  denote  a  formal  rule  with  a  set  of  premises  P  and  a 
conclusion  c.  Let  a  be  some  substitution  of  terms  for  metavariables  such  that 
{j)cr  is  a  generalised  instance  of  the  rule.  Now  suppose  that  r  is  a  hole-filling 
(a  substitution  of  hole-variables  for  term  abstractions  of  the  corresponding 
aritv).  Then  the  following  are  identical  rule-instances: 

where  (err)  denotes  the  application  of  substitution  r  to  the  range  of  a. 

Proof.  It  is  easy  to  see  that  valid  rule-instances  are  closed  under  substitution, 
and  hence  that  {{^)(j)t  is  a  valid  rule  instance.  Since  metavariables  and  hole 
variables  are  distinct,  then  the  equivalence  above  follows  immediately  from 
the  substitution  lemma.  □ 

Other  Syntactic  Categories 

The  idea  of  extending  definitions  to  work  over  contexts  is  widely  applicable. 
Definitions  in  operational  semantics  often  involve  the  construction  of  several 
syntactic  categories  which  either  contain  terms  or  restrict  the  set  of  terms  in 
some  way.  For  example, 

•  The  definition  of  configurations  in  an  SOS-style  semantics  or  in  the  defini¬ 
tion  of  an  abstract  machine  containing  e.g.  stacks  of  terms  or  environments 
(finite  mappings  from  variables  to  terms).  The  definition  of  a  rule-instance 
is  essentially  the  same,  and  so  there  are  no  problems  in  allowing  instances 
to  contain  hole- variables. 

•  The  definition  of  particular  subsets  of  terms,  e.g.,  the  values  in  a  call-by¬ 
value  functional  language  V  ::=  constant  \  (Vi,  V-f)  \  Xx.M  |  . . .  can  be 
lifted  to  “value  contexts”  in  the  obvious  way;  value  metavariables  used  in 
computation  rules  must  then  be  instantiated  with  value  contexts. 

•  A  popular  style  of  small-step  operational  semantics  is  to  use  evaluation  con¬ 
texts  to  describe  a  deterministic  reduction  strategy.  An  evaluation  context, 
usually  specified  by  a  grammar,  is  a  context  with  exactly  one  hole.  For 
example,  the  evaluation  contexts  for  a  call-by-value  lambda  calculus  with 
strict  pairing  and  left-to-right  evaluation  might  be  specified  by 

E::=  []  \  EM  \  VE  \  {E,M)  \  {V,E)  |  ... 

The  evaluation  rules  can  then  be  specified  by  e.g. 

E[{\xM)V\  E|M[V/J] 

Formalising  this  style  of  definition  presents  no  problems  either;  evaluation 
contexts  (for  this  language  at  least)  are  just  abstractions  of  one  variable 
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(the  hole).  Note  that  in  this  particular  example  there  are  three  definitions 
which  need  to  be  generalised:  values,  evaluation  contexts  and  the  evaluation 
rules  themselves.  The  only  precaution  is  to  treat  the  hole  variable  in  the 
definition  of  evaluation  contexts  (which  in  this  example  can  be  taken  to 
have  arity  zero)  as  being  distinct  from  all  other  hole  variables. 


4  Applications 

A  typical  application  of  “direct  reasoning  about  contexts”  is  to  prove  proper¬ 
ties  about  a  contextually-defined  equivalence  relation.  Examples  of  this  style 
of  “direct”  reasoning  can  be  found  in  e.g.,  [MT91,AMST97];  using  the  ap¬ 
proach  described  here  we  can  make  such  arguments  rigorous  with  almost  no 
overhead  in  building  a  language-specific  context  calculus.  We  used  this  tech¬ 
nique  for  several  of  the  results  described  in  [San97],  where  various  theorems 
about  operational  preorders  are  established  for  any  language  whose  opera¬ 
tional  semantics  rules  fit  a  certain  rule  format. 

In  [MS98,Mor98]  the  approach  described  in  this  article  is  used  to  establish 
a  context  lemma  for  call-by-need  lambda  calculi  (in  the  latter  including  a 
form  of  fair  nondeterminism);  in  these  applications  the  semantics  is  based  on 
an  abstract  machine,  rather  than  a  term-based  computation  model. 

Most  applications  of  “context  evaluation”  build  upon  a  small-step  opera¬ 
tional  semantics  of  some  kind.  This  is  natural  since  the  larger  the  computation 
step  which  is  used,  the  less  likely  that  the  computation  step  can  be  applied  to 
a  context.  In  the  remainder  of  this  article  we  consider  an  example  application 
where  a  large-step  semantics  still  yields  some  useful  computations  on  contexts. 

4.1  A  Unique  Fixed-Point  Induction  Theorem 

A  well-known  proof  technique  in  e.g.  process  algebra  involves  syntactically 
characterising  a  class  of  recursion  equations  which  have  a  unique  solution. 
Knowing  that  a  recursive  definition  has  a  unique  fixed  point  means  that  one 
can  prove  equivalence  with  a  recursively  defined  entity  by  showing  that  the 
recursion  equation  is  satisfied. 

The  usual  syntactic  characterisation  is  that  guarded  recursion:  if  recursive 
calls  are  syntactically  “guarded”  by  an  observable  action  then  the  fixed-point 
of  the  definition  is  unique. 

We  illustrate  related  notion  of  guarded  context  for  a  lazy  lambda-calculus 
with  constants,  and  show  -  with  the  help  of  context  evaluation  -  that  guarded 
contexts  enjoy  a  unique  fixed-point  property.  The  process  calculus  notions  of 
guardedness  are  something  of  a  panacea  when  it  comes  to  reasoning  about 
recursion.  Although  the  functional  notion  of  guardedness  falls  a  long  way 
short  of  this,  there  are  still  some  interesting  instances. 

We  will  take  an  extension  of  the  lazy  lambda  calculus  [Abr90]:  The  syntax 
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of  expressions  (M,  N  etc)  is  as  follows: 

M  ::=  X  1  MN  \  Xx.M  (Var;  Apply;  Lambda) 

I  case  L  of  {ci(f i)  Mi... Cn{xn)  M„}  (Case) 

I  c(M)  (Constructors) 

Constructors  have  a  fixed  arity  (>  0),  and  we  implicitly  assume  that  instances 
of  constructor  expressions  and  patterns  always  respect  the  arity.  We  will  use 
a  deductive  (“big-step”)  style  of  semantics; 

The  results  of  computations  are  weak  head-normal  forms  (WHNF):  either 
constructor  terms  c(L)  or  lambda-abstractions  Xx.M.  Let  V ,  W  range  over 
WHNF’s.  Now  we  define  the  convergence  relation  between  closed  terms  by 
the  evaluation  rules  in  figure  1.  As  usual  we  write  M^  to  mean  3N.  MJj-iV  Let 


Xx.M^Xx.M  c(M)4c(M)  Mi  M2W 

case  L  of  {•  •  •  Ci(xi)  ^  Mj  •  •  •}  -DV 


Fig.  1.  Convergence  relation 

C  denote  the  operational  preordering  defined  by  M  ^  W  if  and  only  if  for  all 
conventional  contexts  C  such  that  C{M]  and  CfW]  are  closed  expressions,  then 
C[M]^  implies  CiW]!).  Let  =  denote  the  corresponding  equivalence  relation. 

Now  we  are  in  a  position  to  define  the  guarded  contexts: 

Definition  4.1  The  guarded  contexts,  G,  are  contexts  containing  at  most 
one  hole  variable,  and  given  by  the  following  grammar: 

G  ::=  M  I  c(Hi, . . . , B^)  |  Aa;.B[  |  case  L  of 

Cl(^l)  •  •  •  ^n(^n)  ®7i 

H::=e(M)  |  G 

Since  guarded  contexts  have  just  one  hole  variable,  we  will  write  G[{x)M]  to 
denote  G[(^)M/^]. 

Theorem  4.2  (Unique  Fixed  Point)  For  all  expressions  M ,  N  where  fv(M)\J 
fy(N)  C  X,  the  following  proof  rule  is  valid: 

M  ^  G[{x)M]  N  ^  G[(x)W] 

M^N 

Using  the  justification  given  in  the  previous  section,  we  tacitly  extend  the 
syntactic  categories  and  definitions  of  one-step  reduction  and  of  convergence 
to  allow  the  occurrence  of  hole  variables.  We  will  let  E  range  over  evaluation 
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contexts  containing  hole  variables;  V  and  W  over  weak  head  normal  forms  with 
holes,  and  we  extend  the  definitions  of  one-step  reduction  and  of  convergence 
to  these  extended  syntactic  categories. 

The  main  point  of  the  example  is  that  the  proof  of  the  above  theorem  is 
facilitated  by  the  following  property  of  guarded  contexts: 

Lemma  4.3  For  all  guarded  contexts  G  and  all  abstractions  {x)M  such  that 
G[(^)M]  is  closed, 

3y.  G[(x)M]Jj-V  3V.  G.(J-V 

where  V  is  a  guarded  context  (i.e.  either  of  the  form  Ax.H  or  c(]H[i, . . .  ,H„) 

Proof.  The  (4=)  direction  follows  easily  from  Theorem  3.2,  since  it  follows 
from  G^IV  that  G[{x)M]i^Y[{x)M].  For  the  (=^^)  direction,  we  assume  that 
G[(x)M].||.V^  and  proceed  by  rule  induction  to  show  that  3V.  G^ll-V.  We  proceed 
by  cases  according  to  the  structure  of  G. 

Case  G  =  M:  then  V  is  simply  V. 

Case  G  =  Ax.H:  then  V  is  just  Ax.H.  The  case  for  constructors  follows 
similarly. 

Case  G  =  case  L  of  {ci(xi)  Gi  •  •  •  Cn(^n)  <G„}  :  then  the  rule  for  case 
evaluation  provides  the  following  inductive  hypotheses:  Li^Ci{L)  for  some 
Ci,  and  Gt[-^/^.]j|^V  for  a  guarded  value  context  V.  The  latter  case  relies  on 
the  observation  that  guarded  contexts  are  closed  under  substitution.  Prom 
the  case  evaluation  rule  we  conclude  that  G.(|-V. 

□ 

We  sketch  how  the  proof  of  the  can  be  completed  using  the  technique  of 
“simulation  up  to”  (for  this  particular  language  this  technique  is  described  in 
[San96],  and  is  a  simple  adaptation  of  the  (bi)simulation-style  proof  method). 

Definition  4.4  (Simulation  up  to  C)  A  relation  IZ  is  a  simulation  up  to 
C  if  for  all  M,  N,  whenever  M  1Z  N,  then  for  all  closing  substitutions  a,  if 
Mai^V  then  Nai}-W  for  some  W  such  that  one  of  the  following  two  conditions 
hold: 

(i)  V  =  c{Mi...Mn),W  =  c{Ni...Nn)  andMi^-,n-,£Ni,i€l...n 

(ii)  =  Xx.M'  and  W  =  Xx.N'  and 

Proposition  4.5  If  IZ  is  a  simulation  up  to  ^  then  72.  C  C 

Now  we  can  complete  the  proof  of  the  theorem  by  constructing  a  suitable 
relation  and  showing  that  it  is  a  simulation  up  to  C  (equivalence  follows  by 
symmetry  of  the  argument). 

Suppose  that  M  =  Go[{x)M]  and  N  =  Go[(S)iV].  We  can  assume  without 
loss  of  generality  that  fv(Go)  C  x.  We  will  show  that 

R  =  {G[(x)M],G[(x)Ar]  I  fv(G)  C  x} 

is  a  simulation  up  to  C.  Suppose  that  G[(x)M](7))..  Since  {x)M  is  a  closed 
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abstraction,  G[{x)M]a  =  Ga[{x)M].  Since  Gcr  is  also  a  guarded  context  by 
lemma  4.3  we  have  that  either 

(i)  Qr-ll-Ay.Ho  for  some  Ho,  or 

(ii)  G(T.D-c(Hi  . . .  Hn)  for  some  constructor  c  and  some  Hi . . .  H„. 

By  theorem  3.2  we  know  that  G[(f)A^]cr-D.,  and  it  remains  to  show  that,  in 
each  respective  case  that  Hj[(x)M]^;i2;^Hi[(x)iV].  By  definition  each  Hj  is 
either  a  guarded  context  or  a  hole.  In  the  former  case  we  have  immediately 
that  Hj[(x)M]  i?  Hi[(x)A^]  and  so  we  are  done  by  refiexivity  of  In  the  latter 
case  Hj  is  of  the  form  ^(Z)  so  we  have  that 

mmM]  =  ^  G„t(x)An[i/ii  R(k[(x)m[^k]=N[^ix] 

as  required. 

Example 

We  leave  the  following  example  as  an  exercise  which  is  easily  proved  using 
the  unique  fixed-point  rule: 

map  f  (iterate  f  x)  =  iterate  f  (f  x) 

where  map  : :  (a  ->  b)  ->  [a]  ->  [b]  and  iterate  : :  (a  ->  a)  ->  a  -> 
are  the  usual  Haskell  recursive  functions. 
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Abstract 

Flow  logic  is  a  “fast  prototyping”  approach  to  program  analysis  that  shows  great 
promise  of  being  able  to  deal  with  a  wide  variety  of  languages  and  calculi  for  com¬ 
putation.  However,  seemingly  innocent  choices  in  the  flow  logic  as  well  as  in  the 
operational  semantics  may  inhibit  proving  the  analysis  correct.  Our  main  conclusion 
is  that  environment  based  semantics  is  more  flexible  than  either  substitution  based 
semantics  or  semantics  making  use  of  structural  congruences  (like  alpha-renaming). 


1  Introduction 

Flow  logic  facilitates  the  specification  of  program  analyses  [10]  that  automat¬ 
ically  predict  properties  of  programs  holding  in  all  executions.  It  allows  to 
deal  with  a  wide  variety  of  languages;  examples  include  the  lambda-calculus 
with  side-effects  (a  fragment  of  Standard  ML)  or  communications  (a  fragment 
of  Concurrent  ML),  several  object  based  calculi,  and  a  process  algebra  (the 
TT-calculus).  Analyses  may  be  described  in  a  succinct  form  (akin  to  program 
logic)  or  in  a  more  verbose  form  (taking  the  form  of  constraint  satisfaction); 
also  they  may  be  described  at  an  abstract  level  of  reasoning  (using  coinductive 
techniques)  or  in  a  more  compositional  manner  (using  inductive  techniques). 
This  allows  to  use  the  approach  to  first  sketch  the  analysis,  next  refine  it 
and  prove  it  correct,  and  finally  obtain  an  eflBcient  implementation;  further¬ 
more,  the  development  may  be  firmly  rooted  upon  existing  program  analysis 
technology  and  insights,  rather  than  having  to  start  from  scratch. 

Structural  operational  semantics  similarly  allows  to  deal  with  a  wide  vari¬ 
ety  of  languages.  There  are  many  choices  that  needs  to  be  made  concerning 
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how  to  define  the  semantics:  e.g.  having  small-step  or  big-step  transitions, 
using  environments  or  performing  direct  substitution,  making  use  of  evalua¬ 
tion  contexts  or  having  explicit  rules  for  reduction  in  context.  Many  of  these 
choices  are  seemingly  innocent  in  the  sense  that  they  do  not  affect  the  “mean¬ 
ing”  of  the  language  being  defined;  and  indeed  diflferent  formulations  of  the 
semantics  can  often  be  proved  equivalent  (although  the  proofs  are  sometimes 
quite  laborious). 

This  might  suggest  that  one  could  deal  with  a  new  language  or  calculus  in 
the  following  way:  first  the  syntax  and  informal  meaning  is  defined,  then  the 
program  analysis  is  developed  simultaneously  with  the  operational  semantics, 
and  finally  they  are  consolidated  with  respect  to  one  another  (and  in  particu¬ 
lar  the  analysis  is  proved  correct) .  One  advantage  of  this  approach  is  that  the 
fine  details  of  the  language  definition  are  consolidated  not  only  by  semantic 
considerations  but  also  by  more  pragmatic  considerations  concerning  the  ease 
with  which  programs  can  be  validated  not  to  have  anomalous  behaviour;  we 
believe  that  this  is  a  key  issue  in  designing  languages  that  are  both  theoret¬ 
ically  well-behaved  and  pragmatically  useful.  Another  advantage  is  that  the 
methods  would  then  be  more  likely  to  scale  up  to  “real  life”  languages  because 
different  teams  of  researchers  could  be  responsible  for  different  aspects  of  the 
development;  this  is  a  major  parameter  for  the  success  of  formal  methods  in 
software  engineering  and  is  often  neglected  in  purely  theoretical  studies. 

In  our  experience  the  above  approach  is  fraught  with  problems.  One  reason 
is  that  the  structure,  size  and  complexity  of  the  correctness  proofs  depend  on 
characteristica  of  the  flow  logic  (e.g.  whether  it  is  abstract  or  compositional) 
as  well  as  on  characteristica  of  the  operational  semantics  (e.g.  whether  it 
uses  environments  or  direct  substitution).  In  some  cases  the  choices  may 
“contradict”  one  another  so  that  no  proof  of  correctness  is  possible  and  the 
analysis  or  semantics  has  to  be  changed.  It  is  therefore  important  to  identify 
general  guidelines  concerning  what  complications  are  likely  to  arise  for  what 
combinations  -  in  order  that  the  use  of  formal  methods  in  this  area  may 
become  a  craft  rather  than  a  (black)  art. 

Our  main  conclusion  is  that  environment  based  semantics  is  more  flexible 
than  either  substitution  based  semantics  or  semantics  making  use  of  structural 
congruences  (like  alpha-renaming)  in  terms  of  being  able  to  accomodate  a 
variety  of  specification  styles  for  program  analysis. 

2  Setting  the  Scene 

For  simplicity  this  paper  concentrates  on  an  untyped  lambda-calculus  al¬ 
though  analogous  considerations  apply  to  the  more  advanced  object  based 
and  concurrent  calculi  mentioned  above.  The  pure  untyped  lambda-calculus 
has  the  following  syntax: 

e  G  Exp 

e  ::=  a:  1  fn  X  =>  e  1  e  e 
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X  G  Var 

where  Var  is  an  unspecified  countably  infinite  set 

The  succinct  formulations  of  flow  logic  considered  here  do  not  require  that  all 
program  points  are  made  explicit;  so  there  is  no  need  to  place  explicit  labels  on 
all  subexpressions  (as  in  [9])  or  to  convert  programs  into  “A-normal-form”  (as 
in  [4]).  Instead  we  shall  assume  that  all  function  abstractions  have  initially 
been  alpha-renamed  so  as  to  have  distinct  formal  parameters  that  are  also 
disjoint  from  the  set  of  global  variables,  FV(e*),  of  the  program  of  interest,  e*. 

Often  program  analysis  is  formulated  as  the  demand  to  compute  “the  best” 
(or  least)  analysis  information,  p,  that  pertains  to  a  program,  e*:  p  =  A(e*). 
Here  we  shall  take  the  more  flexible  approach  that  a  piece  of  analysis  informa¬ 
tion,  p,  needs  to  be  validated  with  respect  to  the  program,  e»:  p  [=  e»  (yielding 
TT  or  ff).  On  the  one  hand  this  allows  to  develop  algorithms  for  computing 
“the  best”  analysis  information  [11,5]  and  on  the  other  hand  it  offers  promise 
of  analysing  not  only  closed  systems:  whenever  new  expressions  emerge  from 
the  environment  it  can  be  checked  whether  or  not  the  current  analysis  has  duly 
recorded  all  the  possible  effects  of  these  expressions.  The  ability  to  analyse 
open  systems  is  particularly  important  for  calculi  and  languages  dealing  with 
distribution  and  mobility  of  software. 

Example  2.1  To  give  an  example  of  the  analysis  consider  the  following  simple 
program,  e»,  (in  a  slight  extension  of  the  syntax): 

letrec  g  =  (fn  x  =>  (g  g)) 
in  g  (fn  y  =>  y) 

Here  a  function  g  is  defined  that  ignores  its  parameter  and  calls  itself  recur¬ 
sively  upon  itself;  the  function  is  then  called  with  the  identity  function  as 
parameter. 

We  shall  next  consider  an  analysis  that  is  called  a  control  flow  analysis 
[15,16],  a  closure  analysis  [12,14]  or  a  set  based  analysis  [6].  To  do  so  we  first 
define  the  abstract  environment  p  by: 

p(g)  =  {fn  X  =>  (g  g)} 

p(x)  =  {fn  X  =>  (g  g),  f n  y  =>  y} 

p(y)  =  0 

The  analysis  of  the  program,  e*,  then  amounts  to  a  judgement  of  the  form 
p  ^  e*  :  0 

saying  that  it  will  be  correct  to  stipulate  that  g  is  bound  to  the  recursive 
function  itself,  that  the  formal  parameter  x  is  bound  to  the  recursive  function 
or  the  identity  function,  that  the  formal  parameter  y  is  bound  to  nothing  (cor¬ 
responding  to  the  identity  function  never  being  called),  and  that  the  program 
never  returns  any  function  (corresponding  to  the  fact  that  it  loops  forever). 
To  validate  the  analysis  we  will  encounter  other  judgements  like 

p  [=  fn  X  =>  (g  g)  :  {fn  x  =>  (g  g)} 
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p  ^  f  n  y  =>  y  :  {f  n  y  =>  y} 

Phgg:0 
P  1=  g  (fn  y  =>  y)  :  0 

and  to  make  this  precise  we  need  to  clarify  how  the  judgements,  p  |=  e  :  W, 
are  defined;  this  will  be  the  subject  of  Section  4  after  having  defined  the 
operational  semantics  in  Section  3. 

3  Operational  Semantics 

Let  us  now  start  on  our  first  task:  the  definition  of  the  operational  semantics. 
As  already  indicated  there  are  a  number  of  choices  to  be  made.  Here  we 
shall  just  consider  three  kinds  of  semantics:  a  substitution  based  semantics 
in  the  manner  of  the  A-calculus  [1],  a  structural  operational  semantics  with 
environments  in  the  manner  of  [13]  and  a  variant  involving  explicit  alpha¬ 
renaming  of  bound  variables  (in  the  manner  of  the  structural  congruence  used 
in  process  algebras  like  the  7r-calculus). 

All  of  these  semantics  are  small-step  and  this  is  advantageous  for  the  ability 
to  express  the  correctness  of  looping  programs  and  for  programs  with  concur¬ 
rency.  The  general  form  of  the  correctness  result  then  is  a  subject  reduction 
result: 

if  the  analysis  p  is  acceptable  for  the  expression  e\ 
and  if  ei  evolves  into  62 

then  the  analysis  p  is  acceptable  for  the  expression  e^. 

If  a  big-step  semantics  had  been  used  then  looping  programs^  as  well  as 
concurrent  programs  would  present  obstacles  to  the  development. 

Substitution  based  semantics 

Perhaps  the  simplest  kind  of  operational  semantics  uses  substitutions  rather 
than  environments.  In  this  case  the  operational  semantics  is  given  by  a  judge¬ 
ment  of  the  form 

ei  62 

saying  that  one  step  of  evaluation  of  ei  yields  62-  To  define  the  judgement  it 
is  helpful  to  clarify  that  the  expressions  playing  the  role  of  values  (i.e.  fully 
evaluated  expressions)  are  simply  those  function  abstractions  that  only  contain 
global  variables: 

V  e  Val 

V  ::=fn  X  =>  e  provided  that  FV(fn  a:  =>  e)  C  FV(e*) 

Here  the  set  FV(e)  of  free  variables  of  an  expression  e  is  defined  in  the  standard 
way:  FV(a;)  =  {a:},  FV(fn  a:  =>  e)  =  FV(e)  \  {a;}  and  FV(ei  62)  =  FV(ei)  U 
FV(e2). 

^  Assuming  a  standard  inductive  interpretation  of  big-step  semantics. 
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The  semantics  is  then  defined  by  the  following  standard  axioms  and  in¬ 
ference  rules;  intuitively  we  shall  only  be  interested  in  evaluating  upon  ex¬ 
pressions  whose  only  free  variables  are  among  the  global  ones,  but  formally  it 
suffices  that  this  condition  holds  for  the  values: 

ei  e\ 


ei  62 


ei  62 


62 


Vx  62 


Vi  e'2 


vi  V2  e[a;  i->  ^2]  if  Vx  =  (fn  x  =>  e) 

Here  e[x^v]  denotes  the  expression  e  with  all  free  occurrences  of  the  variable 
X  replaced  by  the  value  v.  Since  the  formal  parameters  were  assumed  to  be 
distinct  from  the  global  variables,  FV(e»),  no  variable  capture  can  take  place; 
hence  there  is  no  need  for  alpha-renaming  any  formal  parameter  and  therefore 
the  formal  parameters  continue  to  be  distinct  from  the  global  variables.  As 
usual  these  axioms  and  rules  are  to  be  interpreted  inductively,  meaning  that 
the  judgement  is  defined  by  what  can  be  obtained  using  the  axioms  and  rules 
and  nothing  else. 


Environment  based  semantics 

A  somewhat  more  complex  semantics  is  obtained  by  using  environments  in¬ 
stead  of  substitutions.  Following  the  pattern  in  [13]  we  need  to  extend  the 
syntax  of  the  language  in  order  to  define  the  structural  operational  semantics. 
The  changes  needed  for  the  extended  syntax  are  as  follows: 

ie  G  lExp 

ie  ::=  x\fnx=>e\ieie\  close  (fn  a:  =>  e)  in  p  |  bind  p  in  ie 

p  6  Env 

p  ::=  [  ]  I  p[a:  !-)■  v] 

V  G  IVal 

V  close  (fn  x  =>  e)  in  p 

The  expression  close  (fn  x  =>  e)  in  p  encapsulates  an  unevaluated  abstraction 
fn  re  =>  e  with  an  environment  p  that  gives  values  to  all  the  free  variables 
in  fn  X  =>  e;  this  construct  is  needed  because  we  have  decided  to  design  a 
semantics  using  environments.  The  expression  bind  p  in  ie  encapsulates  a 
partly  evaluated  expression  ie  with  a  local  environment  p;  this  construct  is 
needed  because  we  have  decided  to  design  a  small-step  semantics.  Note  that  we 
retain  the  distinction  between  unevaluated  expressions,  e  G  Exp,  and  partly 
evaluated  (or  intermediate)  expressions,  ie  G  lExp,  in  order  to  clarify  the 
precise  points  where  partly  evaluated  expressions  may  occur;  this  will  prove 
helpful  when  reasoning  about  the  analysis.  Finally,  (intermediate)  values  are 
just  closures,  and  environments  are  lists  of  mappings  from  variables  to  values: 
we  write  p[x  i->  u]  for  the  environment  p  augmented  such  that  the  variable  x 
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now  maps  to  the  value  u;  if  there  is  more  than  one  binding  for  a  given  variable 
we  always  use  the  rightmost  (most  recent)  one. 

The  operational  semantics  is  given  by  a  judgement  of  the  form: 

p  h  ie\  ie2 

Here  p  is  the  environment  in  which  the  expression  is  to  be  evaluated.  It  is 
defined  by  the  following  standard  axioms  and  inference  rules: 

p\-  X  V  if  p(x)  =  V 

p  h  (fn  X  =>  e)  (close  (fn  x  =>  e)  in  p) 

h*  *  •  / 

,  ie\  — > 
p  h  iei  ie2  ie[  ie2 

h*  E  •  •  / 

ie2  — ^  1^2 

p\-  Vi  162  Vi  162 

p\-  Vi  V2  (bind  pi[x  V2]  in  e)  if  Vi  =  (close  (fn  x  ->  e)  in  pi) 

_ ,  ^  ^el  — >  i6\ _ 

p  h  (bind  p\  in  iei)  (bind  pi  in 
p  h  (bind  pi  in  Ui)  Vi 

Once  again  this  definition  is  to  be  interpreted  inductively. 


Explicit  alpha-r6naming 

Let  us  finally  consider  a  variation  of  the  environment-based  semantics  where 
there  is  an  explicit  rule  for  alpha-renaming  the  bound  variable  of  an  abstrac¬ 
tion.  This  will  allow  us  to  illustrate  some  of  the  difficulties  that  will  emerge 
when  analysing  process  calculi  like  the  7r-calculus  where  a  structural  congru¬ 
ence  (containing  alpha-renaming)  is  defined  and  incorporated  into  the  seman¬ 
tics. 

The  operational  semantics  is  then  given  by  a  judgement  of  the  form: 
p  h  iei  162 

As  above  p  is  the  environment  in  which  the  expression  is  to  be  evaluated.  The 
inductive  definition  is  given  by 

analogues  of  the  axioms  and  rules  given  for 


together  with  the  rule 


16  =a  16 


p  h  ie 


16 


16"  =a  16"' 


Ea. 


p\-  i6  16" 

where  ie  =a  ie'  denotes  that  16  is  equivalent  to  ie'  modulo  alpha-renaming  (of 
formal  parameters). 

A  similar  modification,  is  possible  for  the  substitution  based  seman¬ 
tics;  we  shall  write  when  it  is  not  of  any  importance  whether  we  refer 

i  Ea. 

to  — y  or 


So, 
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4  Flow  Logic 

Let  us  now  turn  to  our  second  task;  the  specification  of  the  program  anal¬ 
ysis.  As  already  indicated  there  are  a  number  of  choices  to  be  made.  Here 
we  shall  concentrate  on  an  abstract  specification  (in  the  manner  of  abstract 
interpretation  [2]),  a  compositional  (or  syntax-directed)  specification,  and  a 
specification  using  representations  of  expressions.  We  shall  only  be  concerned 
with  specifying  how  to  check  that  a  proposed  solution  is  indeed  acceptable; 
the  existence  of  “best”  (or  least)  acceptable  solutions  is  treated  in  [9,5,11]. 
Also  we  shall  only  deal  with  succinct  specifications  as  they  exhibit  a  logical 
flavour  that  is  well  suited  for  semantic  considerations. 

4.1  Abstract  Specification 

The  most  general  approach  is  motivated  by  the  considerations  of  the  collecting 
semantics  (static  semantics  [2])  in  abstract  interpretation  and  works  well  for 
open  systems.  Here  the  judgement 

p^e:W 

expresses  that  the  pair  (fiW)  is  an  acceptable  analysis  for  the  expression 
e:  the  W  component  describes  the  set  of  function  abstractions  that  e  could 
result  in  and  the  p  component  describes  the  set  of  function  abstractions  that 
the  variables  inside  e  could  be  bound  to.  It  is  defined  by  the  following  clauses: 

p^x:W  iflf  p{x)  C  W 

p  \=^  fn  X  =>  e  ’.W  iff  {f n  x  =>  e}  QW 

p  h  ei  62  :  W  iff  3Wi,  W2  :  p  h  A  p  ^  62  :  Wj  A 

V(fn  X  =>  e')  €  Wi  :  3W' :  W2  C  p{x)  A  p^e':W'  A  W'CW 

The  axiom  for  variables  is  straightforward:  since  the  abstract  environment 
records  the  set  of  abstract  values  that  the  variable  can  be  bound  to,  we  just 
ensure  that  this  set  is  part  of  the  set  of  abstract  variables  that  can  result  from 
the  expression.  Also  the  axiom  for  function  abstractions  is  straightforward: 
a  function  abstraction  gives  rise  to  a  single  abstract  value  and  we  ensure 
that  it  is  part  of  what  can  result  from  the  expression.  The  rule  for  function 
applications  is  a  bit  more  complex.  First  we  must  verify  that  the  analysis 
is  correct  as  regards  the  operator  part  and  as  regards  the  operand  part.  For 
each  possible  function  being  applied,  we  then  “link”  the  abstract  values  for  the 
actual  parameter  to  those  for  the  formal  parameter,  we  verify  that  the  analysis 
is  correct  as  regards  the  body  of  the  function  being  called,  and  finally  we  “link” 
the  abstract  values  from  the  function  body  into  those  of  the  application  itself. 

This  definition  is  appropriate  for  open  systems  because  at  the  function 
application  we  analyse  the  body  of  the  function  actually  being  called  rather 
than  assuming  that  it  is  part  of  the  program  in  question  and  that  it  has  already 
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been  analysed.  Hence  the  functions  called  can  be  allowed  to  come  from  the 
environment,  e.g.  from  a  library  or  from  the  arguments  being  supplied  to  the 
program  in  question. 

The  need  for  coinduction 

There  remains  the  problem  of  ensuring  that  the  clauses  displayed  above  do  in 
fact  define  a  relation,  p  |=  e  :  W,  for  each  expression  e.  This  is  complicated 
by  the  fact  that  the  definition  is  not  syntax-directed:  in  the  clause  for  func¬ 
tion  application  we  perform  an  analysis  of  an  expression  that  need  not  be  a 
subexpression  of  the  function  application  in  question. 

The  remedy  is  standard:  we  need  to  interpret  the  clauses  coinductively  [9]. 
To  do  so  we  regard  the  clauses  as  defining  a  function 

S  :  P(AEnv  x  Exp  x  AVal)  -»  P(AEnv  x  Exp  x  AVal) 

that  operates  over  sets  of  triples  of  the  form  {p,e,W)  where  p  G  AEnv, 
e  G  Exp,  W  G  AVal,  AEnv  =  Var  ->  AVal,  AVal  =  ^^(Exp^”)  and 
Exp-^"  is  the  set  of  function  abstractions  in  Exp.  The  result  of  S{S)  is 
defined  by  combining  the  effect  of  all  the  clauses  except  that  any  occurrence 
of  p'  1=  e'  :  W  on  the  right  hand  side  is  replaced  by  (p',  e',  W)  G  S.  We 
shall  omit  the  detailed  definition  of  <S  but  merely  note  that  the  function  S  is 
monotonic.  By  Tarski’s  Theorem  [17]  it  follows  that  S  has  a  complete  lattice 
of  fixed  points.  The  least  fixed  point  corresponds  to  the  standard  inductive 
interpretation  of  the  clauses  whereas  the  greatest  fixed  point  corresponds  to 
a  coinductive  definition  [8,3]. 

By  taking  the  coinductive  interpretation  of  the  clauses  above  we  obtain 
the  desired  definition  of  p  |=  e  :  W.  By  reasoning  similar  to  the  one  in  [9]  it 
follows  that  there  always  exists  a  least  (or  best)  analysis  that  is  acceptable  in 
the  manner  of  the  above  clauses;  in  particular  this  means  that  all  programs 
can  be  analysed  as  should  not  be  surprising  since  one  can  simply  pretend  that 
all  function  abstractions  can  reach  all  places. 

The  extended  language 

Let  us  now  pause  a  moment  and  think  ahead.  In  case  the  analysis  is  to  be 
validated  with  respect  to  the  environment  based  semantics  we  will  likely  have 
to  analyse  also  the  extensions  to  the  syntax.  This  calls  for  adding  the  following 
clauses 

p  [=  close  (fn  X  =>  e)  i.n  p\W  iff  {f  n  x  =>  e}  QW  A  p  TlA  p 

p  h  bind  p  in  ie'  -.W  iS  3W' :  p  ^  ie' :  W  A  W  CW  A  p  p 

(as  well  as  changing  the  ei  62  above  to  be  ie\  ^62).  The  auxiliary  relation  'RA 
ensures  that  the  entities  encapsulated  in  the  environments  have  been  properly 
analysed  and  it  is  defined  by: 

pRA  p  iff  Va:  G  dom(p)  :  Vya,,  63,,  Px  : 
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{p{x)  =  close  (fn  yx  =>  Cx)  in  px)  => 

({f  n  yx  =>  Bx}  C  p{x)  A  Px  p) 

It  is  immediate  that  the  auxiliary  relation  'RA  is  well-defined:  in  each  recursive 
call  the  environment  gets  smaller.  The  overall  collection  of  clauses  is  then 
interpreted  coinductively  as  before. 

Semantic  correctness 

Let  us  now  consider  the  possibility  of  proving  the  specification  of  the  analysis 
correct.  Recall  that  this  takes  the  form  of  a  subject  reduction  result: 

if  the  analysis  p  is  acceptable  for  the  expression  ei 
and  if  ei  evolves  into  62 

then  the  analysis  p  is  acceptable  for  the  expression  e^. 

(Clearly  the  detailed  formulations  depend  on  the  semantics  used;  they  will  be 
spelled  out  in  detail  as  part  of  the  proofs.) 

Proposition  4.1  The  possibility  of  proving  the  analysis  correct  with  respect 
to  the  semantics  is  given  by  the  following  table: 


A 

s  ^ 

no 

E  ^ 

yes 

a  ^ 

no 

Proof.  In  each  case  we  must  begin  with  clearly  formulating  the  correctness 
statement  and  then  either  disprove  it  by  means  of  an  example  or  conduct 
a  formal  proof.  For  the  substitution  based  semantics  the  subject  reduction 
result  reads  as  follows: 

Vp,  W,  ei,  62  :{p\=  ei'.W  A  ei  62)  ^  {p\=  e2:W) 

To  disprove  this  we  shall  take  ei  =  (fn  x  =>  (fn  y  =>  y)  (fn  z  =>  x))  (fn  u  =>  u), 
62  =  (fn  y  =>  y)  (fn  z  =>  (fn  u  =>  u)),  p(x)  =  {fn  u  =>  u},  p(y)  =  {fn  z  =>  x}, 
p(z)  =  0,  p(u)  =  0,  and  W  =  {fn  z  =>  x}. 

For  the  environment  based  semantics  the  subject  reduction  result  reads  as 
follows: 


A  ^ 

Vp,  W’,iei,ie2,p :  {p  ^  iei  :W  A  p  RA  p  A  p  h  iei  *62)  =?►  (p  [=  ie2  ■  W) 

We  proceed  by  induction  on  p  h  zci  — ^  ie2-  In  several  cases  we  make  use  of 
the  lemma 

if  p  1=  6  :  Wi  and  W\  C  W2  then  p  f=  e  :  W2 

A 

that  can  be  proved  by  inspecting  each  of  the  clauses  defining  ^  in  turn. 
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The  negative  result  for  holds  for  as  well  as  (assuming 

that  the  correctness  statements  are  analogues  of  those  displayed  above).  In 
the  case  of  one  takes  ei  =  (fn  x  =>  (fn  y  =>  y)  (fn  z  =>  z))  (fn  u  =>  u), 
62  =  (f n  y  =>  y)  (fn  v  =>  v),  p{x)  =  {fn  u  =>  u},  p(y)  =  (f n  z  =>  z},  p(z)  =  0, 
p(u)  =  0,  p(v)  =  0,  and  W  =  {fn  z  =>  z}.  The  proof  in  the  case  of  is 
similar.  ^ 

Remark 

Given  the  lemma  in  the  proof  of  Proposition  4.1  it  might  seem  that  one  could 
simplify  the  clauses  for  by  not  writing  all  constraints  explicitly  in  all  clauses: 
one  could  consider  adding  a  clause  saying  that  p\^  e  :W2  iff  :  Wi  C 
W2  A  p\=e:Wi  and  then  the  clause  for  function  abstractions  would  simply 
read  p  |=  fn  x  =>  e  :  {fn  x  =>  e}  and  “similarly”  for  the  other  clauses. 
This  is  indeed  a  common  trick  used  in  (inductively  defined)  type  systems  but 
unfortunately  it  turns  out  to  be  problematic  for  the  (coinductively  defined) 
clauses  here.  The  reason  is  that  the  coinductive  interpretation  of  the  revised 
definition  of  [=  yields  the  relation  that  is  universally  true  (because  of  the 
ability  to  take  Wi  =  W2)!  -  So  to  allow  the  simplifications  (as  is  done  in 
[11])  one  needs  a  more  sophisticated  way  of  interpreting  the  clauses  (and  the 
offending  clause  must  not  be  added). 

4.2  Compositional  Specification 

In  order  to  obtain  a  specification  that  is  readily  implementable  one  usually 
needs  to  proceed  in  a  more  syntax-directed  manner.  This  amounts  to  checking 
the  bodies  of  functions  when  they  are  “defined”  rather  than  when  they  are 
called.  One  problem  with  this  approach  is  that  we  may  then  end  up  analysing 
the  bodies  of  functions  that  are  never  called;  this  can  be  remedied  by  adding 
a  reachability  component  to  the  analysis  (see  e.g.  [5])  but  for  conciseness  of 
the  presentation  we  shall  abstain  from  doing  so.  Another  problem  with  this 
approach  is  that  we  then  confine  the  attention  to  closed  systems:  we  cannot 
deal  with  functions  that  are  not  part  of  the  program  in  question  (or  some  a 
priori  given  library  or  set  of  arguments  to  the  program). 

Analysing  function  bodies  when  “defined”  then  necessitates  an  additional 
component  to  the  analysis:  a  mechanism  for  ensuring  that  the  set  of  function 
abstractions  that  can  result  from  the  body  will  be  known  at  all  relevant  ap¬ 
plication  points.  Since  we  have  assumed  that  all  function  abstractions  have 
initially  been  alpha-renamed  to  have  distinct  formal  parameters,  it  makes 
sense  to  use  the  formal  parameter  as  the  unique  identifier  for  the  function 
abstraction  in  question.  We  then  extend  the  global  analysis  information,  p,  to 
contain  a  component  p{x=>)  =  W  whenever  the  body  of  f  n  x  =>  e  may  yield 
W  (just  as  p(x)  =  W  whenever  the  formal  parameter  of  fn  x  =>  e  may  be 
bound  to  abstract  values  from  W). 

With  these  preparations  we  can  then  define  a  judgement  of  the  form 
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p^e:W 

for  expressing  that  the  pair  {p,  W)  is  an  acceptable  analysis  for  the  expression 
e  and  bearing  in  mind  that  the  domain  of  p  is  larger  than  in  the  abstract 
specification.  The  judgement  is  defined  by  the  following  clauses: 

p^x:W  iff  p{x)  C  W 

p  [=  fn  a;  =>  e  :  W  iff  {fn  a;=>e}CW  Ap|=e:  p{x=>) 

p^eie2-.W  iff  BWi,W2  :  p  h  ei  :  ^  A  p  ^  63  :  TT2  A 
V(fn  X  =>  e')  G  Wi  :  W2  Q  p{x)  A  p{x=>)  C  W 

Unlike  the  abstract  specification  there  is  no  need  to  rely  on  a  coinductive  def¬ 
inition  because  the  specification  is  purely  compositional  (or  syntax-directed); 
however,  there  is  no  harm  in  viewing  the  specification  as  being  a  coinduc¬ 
tive  definition  because  the  coinductive  and  inductive  definitions  turn  out  to 
agree  (and  on  philosophical  grounds  one  might  indeed  argue  that  one  should 
continue  to  stress  the  fact  that  the  specification  is  coinductive)! 

The  extended  language 

Looking  ahead  to  possibly  using  the  environment  based  semantics  for  validat¬ 
ing  the  analysis  there  once  more  is  the  need  to  analyse  the  extensions  to  the 
syntax.  This  calls  for  adding  the  following  clauses: 

p  [=  close  (f  n  X  =>  e)  i-n  p  •.  W  iff  {f  n  a:  =>  e}  C  A  p  TiP  p  A  p  ^  e  :  p{x->) 

p  1=  bind  p  in  ie'  :  W  iff  BW  :  p^  ie'  •.  W'  A  W  C.W  /\  p  'Rp  p 

(as  well  as  changing  the  ei  63  above  to  be  iei  263).  The  auxiliary  relation  'Rp 
is  defined  as  follows: 

p  Rp  p  iff  Va;  G  dom(p)  :  Vt/x,  ^x,  Px  '■ 

{p{x)  =  close  (fn  yx  =>  e^)  in  px)  => 

C 

({fn  Vx  =>  ex}  C  p{x)  A  pxRP  p  A  p  \=  Cx  :  p{yx=>)) 

It  is  now  slightly  more  tricky  to  ensure  that  the  analysis  and  the  auxiliary 
relation  are  well-defined  since  they  depend  recursively  upon  one  another.  One 
possibility  is  to  use  mathematical  induction  on  n  to  prove  that  p  \=  e  :  W 
and  p  p  are  well-defined  whenever  the  size  of  e  and  p  is  at  most  n;  here 
the  size  may  be  taken  to  be  the  finite  number  of  ASCII  characters  needed  to 
represent  the  entity. 

Relationship  between  the  specifications 

We  said  above  that  the  abstract  and  compositional  specifications  differ  be¬ 
cause  we  did  not  include  a  reachability  component.  Indeed,  once  this  is  done 
along  the  lines  of  [5]  one  can  establish  an  equivalence  result  between  the  two 
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specifications.  To  give  the  fiavour  of  this  result  we  state  without  proof  the 
following  weaker  fact  that  holds  for  the  analyses  as  defined  here;  it  says  that 
(for  closed  systems)  all  acceptable  analyses  with  respect  to  the  compositional 
specification  are  also  acceptable  with  respect  to  the  abstract  specification. 

Fact  4.2  Let  e»  be  the  given  program,  let  Exp,,  he  the  set  of  subexpressions 
of  e^,  and  let  Exp{^  be  the  set  of  function  abstractions  in  e*.  Assuming  that 
all  p{x)  and  W  are  restricted  to  be  subsets  of  Exp{'^,  i.e.  AVal  —  V{Expl^), 
we  have 

A  c 

p  1=  e*  :  kF  ^  p  1=  e»  :  W. 

The  opposite  implication  need  not  hold;  as  an  example  take  p(x)  =  0,  p(y)  =  0, 
p(z)  =  0,  kF  =  0  and  consider  e,  =  (fn  x  =>  (fn  y  =>  y)  (fn  z  =>  z)). 


Semantic  correctness 

Let  us  now  consider  the  possibility  of  establishing  a  subject  reduction  result 
for  this  analysis. 

Proposition  4.3  The  possibility  of  proving  the  analysis  correct  with  respect 
to  the  semantics  is  given  by  the  following  table: 


C 

H 

5  ^ 

no 

E  ^ 

yes 

a  ^ 

no 

Proof.  For  the  substitution  based  semantics  the  subject  reduction  result 
reads  as  follows: 

Vp,  kF,  ei,  62  :  (p  1=  ^  ^  ®2)  (p  h  ^2  :  kF) 

To  disprove  this  statement  we  proceed  as  in  the  proof  of  Proposition  4.1. 

For  the  environment  based  semantics  the  subject  reduction  result  reads  as 
follows: 


Vp,  W,ie\,ie2, p :  (p  [=  ici  :  kF  A  p  p  A  p  h  iei  ^62)  =>  (p  |=  *62  :  kF) 

We  proceed  by  induction  on  p  h  iei  ie2.  In  several  cases  we  make  use  of 
the  lemma 

\{  p  \=  e  :W\  and  kFi  C  kF2  then  p  ^  e  :  kF2 

c 

that  can  be  proved  by  inspecting  each  of  the  clauses  defining  |=  in  turn. 

The  negative  result  for  holds  for  as  well  as  (assuming 

that  the  correctness  statements  are  analogues  of  those  displayed  above);  it 
may  be  proved  as  in  the  proof  of  Proposition  4.1.  □ 
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4-3  Representations  of  Expressions 

In  terms  of  implementing  the  compositional  analysis  it  would  seem  that  we 
are  carrying  a  lot  of  useless  baggage  around:  the  complete  function  bodies. 
This  suggests  defining  a  modified  analysis  that  just  uses  representations  of 
functions.  Given  our  assumption  that  all  function  abstractions  in  the  given 
program  have  initially  been  alpha-renamed  so  as  to  have  distinct  formal  pa¬ 
rameters,  it  makes  sense  to  let  fn  x  serve  as  a  representation  of  f  n  x  =>  e.  We 
then  define  the  judgement 

CR 

p^e-.W 

c 

by  the  following  clauses  that  are  rather  directly  obtained  from  those  for  |=  : 

OR 

p^x:W  iflf  p{x)  C  W 

CR  CR 

p  1=  fn  a;  =>  e  :  W  iflf  {f n  re}  C  W  A  p  \=  e  :  p{x=>) 

CR  CR  CR 

p  \=  Cl  62  '.W  iff  3Wi ,  W2  :  p  \=  Cl  :  Wi  A  p  \=  €2  :  W2  A 
V(fn  x)  6  :  W2  C  p(x)  A  p(x=>)  C  W 

The  extended  language 

The  clauses  relevant  for  the  extensions  to  the  syntax  are  minor  variations  of 
those  considered  before: 

p  1=  close  (fn  X  =>  e)  in  p:W  iff  {f n  x}  C  W  A  p  p  A  p  f=  e  :  p{x->) 

OR  CR  __ 

p  bind  p  in  ie'  :  W  iff  3W’ :  p  \=  ie'  :  W  A  W*  CW  A  p  Rp^  p 

Finally,  the  definition  of  the  auxiliary  relation  is  obtained  from  the  one 
for  RP-. 

p  R^^  p  iff  Vx  e  dom(p)  :  Vya,,  e^,  Px  ■ 

(p(x)  =  close  (fn  px  =>  e^)  in  p*) 

CR 

({fn  Px}  C  p(x)  A  Px  RP^  p  A  p  1=  Ca;  :  p{px=>)) 

Well-definedness  of  these  definitions  follows  as  for  the  compositional  specifi¬ 
cation. 

Relationship  between  the  specifications 

Intuitively  the  two  compositional  specifications  should  be  equivalent  because 
the  body  of  a  function  abstraction  is  not  used  to  carry  any  information.  We 
state  without  proof  the  following  fact;  it  states  an  equivalence  result  for  closed 
systems. 

Fact  4.4  Let  e*  be  the  given  program,  let  Exp,,  be  the  set  of  subexpressions  of 
e»  and  let  Exp{'^  be  the  set  of  function  abstractions  in  e».  Writing  ret{W)  = 
{(fn  x)  I  (fn  X  =>  e)  €  W}  and  assuming  that  all  p(x)  and  W  are  restricted 

13 


Nielson 


to  be  subsets  ofExpl'^,  i.e.  AVal  =  'P{Exp{'^),  we  have 

C  CR 

e*  :  W  (reto  p)  |=  e»  :  ret{W) 

Furthermore,  writing  exp{W)  =  {(fn  x  =>  e)  E  Exp^  \  (fn  x)  E  W}  and 
assuming  that  all  p{x)  and  W  are  restricted  to  be  subsets  of  ret(Exp{,^), 
i.e.  AVal=  V{ret{Expl'^)),  we  have 

C  CR 

{exp op)  1=  e*  :  exp{W)  p  [=  e*  :  VF 

Note  that  exp{W)  produces  exactly  the  same  number  of  elements  as  in  W 
given  our  assumption  that  all  function  abstractions  have  initially  been  alpha- 
renamed  to  have  distinct  formal  parameters. 


Semantic  correctness 

The  use  of  representations  of  expressions  rather  the  expressions  themselves 
turns  out  to  facilitate  establishing  an  analogoue  of  a  subject  reduction  result 
that  defeated  us  earlier. 

Proposition  4.5  The  possibility  of  proving  the  analysis  correct  with  respect 
to  the  semantics  is  given  by  the  following  table: 


CR 

h 

s  ^ 

yes 

E  ^ 

yes 

Ot  ^ 

no 

Proof.  For  the  substitution  based  semantics  the  subject  reduction  reads  as 
follows; 

CR  CR 

Vp,  W,  61,62  :  {p  \=  6i:W  A  61  62)  {p  ^  e2-.W) 

The  proof  is  by  induction  on  61  62.  For  (fn  x  =>  e)  V2  e[x  !->•  ^2]  we 

use  the  lemma 

CR  CR 

if  p  1=  e  :  Wi  and  Wi  C  W2  then  p  f=  e  :  W2 

CR 

(that  can  be  proved  by  inspecting  each  of  the  clauses  defining  |=  in  turn) 
and  also  the  lemma 

CR  CR  CR 

if  p  1=  e  :  W  and  p  \=  v  :  p{x)  then  p  \=  e[x  v]  :  W 

(that  can  be  proved  by  structural  induction  on  e)  and  we  also  use  the  fact 
that  no  variable  capture  can  take  place  in  6\x  u]  (because  if  u  is  a  value 
then  FV(u)  C  FV(e*)  and  the  set  of  formal  parameters  is  disjoint  from  the  set 
of  global  variables,  FV(e*)). 

For  the  environment  based  semantics  the  subject  reduction  result  reads  as 
follows: 
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Vp,  W,iei,ie2,/0  :  {p\=iex:W  A  p  'RP^  p  A  p\-iei-^  162)  (p  \=  ie2  :  W) 

For  the  proof  we  proceed  as  in  the  proof  of  the  corresponding  case  in  Propo¬ 
sition  4.3. 

The  negative  result  for  holds  for  as  well  as  (assuming 

that  the  correctness  statements  are  analogues  of  those  displayed  above);  it 
may  be  proved  as  in  the  proof  of  Proposition  4.3.  □ 

Representations  of  expressions  for  abstract  specification 
The  reader  might  wonder  whether  it  is  only  in  the  case  of  compositional  spec¬ 
ifications  that  it  is  possible  to  work  with  representations  of  expressions  rather 
than  the  expressions  themselves.  In  the  Appendix  we  shall  show  that  it  is 
indeed  possible  to  do  so  for  abstract  specifications  although  the  resulting  spec¬ 
ification,  t=5  is  not  of  interest  because  the  analysis  is  much  coarser  than  the 
other  analyses. 

5  Conclusion 

Flow  Logic  is  by  no  means  the  first  approach  to  formulating  program  analyses 
in  a  logical  form.  However,  in  our  view  it  is  the  first  approach  that  aims  at 
integrating  the  insights  from  existing  program  analysis  technologies  (such  as 
data  fiow  analysis,  control  flow  analysis  and  abstract  interpretation)  into  a 
common  form  that  is  applicable  to  a  wide  variety  of  programming  languages. 
This  then  motivates  the  current  investigation  into  the  relative  usefulness  of 
different  kinds  of  semantics. 

The  technical  results  concerning  the  possibility  of  proving  the  analyses 
correct  may  be  summarised  as  follows  ^  : 


A 

h 

c 

h 

CR 

h 

AR 

h 

5  ^ 

no 

no 

yes 

(yes) 

E  ^ 

yes 

yes 

yes 

(yes) 

a  ^ 

no 

no 

no 

C  CR 

Here  ^  and  [=  are  equally  precise  (Fact  4.4)  and  only  “slightly  coarser” 

A  AR 

than  \=  (Fact  4.2)  whereas  \=  is  so  coarse  as  to  be  of  no  interest  (Fact  A.l). 
The  table  clearly  shows  that  the  environment  based  semantics  is  more  flexible 
than  either  substitution  based  semantics  or  semantics  making  use  of  structural 
congruences  ^  (like  alpha-renaming)  in  terms  of  being  able  to  accomodate  a 

^  We  refer  to  the  Appendix  for  the  missing  entry. 

^  Current  work  on  the  7r-calculus  studies  techniques  aimed  at  overcoming  some  of  these 
difficulties;  this  involves  changing  the  syntax  of  the  language  so  as  to  contain  “markers”  for 
all  entities  that  are  not  invariant  under  the  congruence. 
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variety  of  specification  styles  for  program  analysis. 

In  our  view  it  is  easiest  to  develop  a  correct  and  useful  program  analysis 
if  one  proceeds  as  follows: 

•  begin  by  developing  an  abstract  specification. 

This  is  particularly  so  for  novel  calculi  involving  distribution  and  mobility 
because  abstract  specifications  are  able  to  deal  with  open  systems.  Also  one 
is  less  likely  to  fail  to  observe  that  the  compositional  specifications  restrict 
themselves  to  closed  systems  and  that  a  reachability  component  is  needed  in 
order  to  obtain  the  same  precision  as  in  the  abstract  specification. 

In  order  to  establish  semantic  correctness  by  means  of  a  subject  reduction 
result  it  is  a  general  principle  that: 

•  the  analysis  information  should  remain  invariant  under  evaluation. 

As  we  have  seen  this  puts  severe  demands  on  the  choice  of  operational  seman¬ 
tics:  one  is  more  or  less  forced  to  abandon  working  with  a  simple  substitution 
based  semantics  in  order  to  work  with  a  more  complex  environment  based 
semantics;  unfortunately,  (in  keeping  with  [13])  this  requires  “artificial”  ex¬ 
tensions  to  the  syntax,  that  then  also  have  to  be  analysed  thereby  reducing 
the  level  of  abstraction  of  the  reasoning. 

We  believe  that  a  compositional  (or  syntax-directed)  specification  is  a  pre¬ 
requisite  for  obtaining  an  efficient  implementation.  As  was  explained  above, 
this  involves  restricting  the  attention  to  closed  systems.  The  development  in 
Section  4.2  is  semi-compositional  [7]  in  the  sense  that  all  expressions  consid¬ 
ered  are  subexpressions  of  the  given  program;  however,  semi-compositionality 
does  not  suffice  for  having  a  free  choice  between  using  environment  based 
or  substitution  based  semantics.  To  achieve  this  we  used  representations  of 
expressions  in  Section  4.3. 

In  this  paper  we  have  only  considered  succinct  specifications  and  have 
ignored  the  verbose  formulations  of  fiow  logic  that  are  likely  to  be  needed 
in  order  to  obtain  an  efficient  implementation.  One  further  principle  worth 
stating  is  that: 

•  explicit  program  points  (in  the  form  of  labelling  all  subexpressions  [9]  or  de¬ 
manding  all  expressions  to  be  in  “A-normalform”  [4])  are  needed  for  verbose 
formulations  but  not  for  succinct  specifications. 

For  the  succinct  formulations  considered  in  this  paper  we  merely  assumed 
that  all  function  abstractions  had  initially  been  alpha-renamed  so  as  to  have 
distinct  formal  parameters  that  were  also  distinct  from  the  global  variables. 
We  refer  to  [11]  for  how  to  transform  a  succinct  specification  into  a  more 
verbose  specification  and  to  [5]  for  an  example  of  how  a  verbose  specification 
may  be  implemented. 
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A  Representations  of  Expressions  for  Abstract  Specifi¬ 
cation 

In  this  appendix  we  show  that  it  is  possible  to  use  representations  of  ex¬ 
pressions  also  for  abstract  specifications,  although  the  resulting  analysis  is  so 
coarse  as  to  be  of  little  interest. 

So  let  us  define  a  judgement 

AR 

p^e:W 

by  the  following  clauses: 

AR 

p^x:W  iflf  p{x)  C  W 

AR 

p  f=  fn  X  =>  e  :  W  iff  {fn  x}  CW 

AR  AR  AR 

p  h  ei  ea  :  W"  iff  3Wi,W2  :  p  ^  ei  :  Wi  A  p  ^  €2  :  A 

AR 

V(f  n  x)eWx:  Ve'  :  3W' :  W2  C  p{x)  A  p\=  e'  :W'  A  W  CW 
For  completeness  sake  we  also  list  the  clauses  for  the  extended  syntax: 

p  p  close  (fn  X  =>  e)  in  p:W  iff  {fn  x}  CW  A  p  p 
p  p  bind  p  in  ie'  -.W  iff  3W' :  p  ^  ie'  -.W'  A  W'  CW  A  p  p 

The  definition  of  the  auxiliary  relation  then  is: 
p  p  iff  Vx  €  dom(p)  :  Px  : 

{p{x)  —  close  (fn  Vx  =>  ex)  in  Px)  ^  ({fn  yAf  C  p{x)  A  Px  p) 

Relationship  between  the  specifications 

The  following  result  shows  that  the  only  acceptable  analysis  for  unevaluated 
programs  is  the  one  that  says  that  all  function  abstractions  can  reach  all 
places.  For  the  formal  statement  we  need  a  few  preparations.  First  note  that 
an  expression  in  the  original  syntax  is  either  an  application,  a  variable  or  a 
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function  abstraction;  if  it  is  an  application  it  can  be  “maximally  expanded” 
into  one  of  the  forms  {{{x  ei)  62)  •  •  •  e„)  or  ((((fn  y  =>  e)  Ci)  62)  •  •  •  e„)  (for 
n  >  0).  To  get  access  to  the  variable  x  occurring  to  the  very  left,  if  indeed 
such  a  variable  exists,  we  shall  define  the  set  LV(e*)  as  follows;  LV(x)  =  {x}, 
LV(fn  X  =>  e)  =  0  and  LV(ei  62)  =  LV(ei).  Clearly  LV(e*)  contains  at  most 
one  element. 

Fact  A.l  Let  e*  be  the  given  program  and  suppose  that  it  is  an  application 
(i.e.  it  is  not  a  variable  or  a  function  abstraction),  that  Vx  E  LV(ef)  :  p{x)  ^  0 
and  that  (for  all  x)  p{x)  and  W  are  restricted  to  be  subsets  of  ret{Exp^'^) 
where  ret{W)  =  {(fn  x)  |  (fn  x  =>  e)  G  VT}  and  Exp^'^  is  the  set  of  function 
abstractions; 

if  p  1=  e»  :  VF  then  Vx  :  p(x)  =  ret{Exp^"')  and  W  =  ret{Exp^^). 


Proof  (sketch).  The  key  to  the  proof  is  that  in  the  clause  for  applica¬ 
tion  we  can  choose  e'  =  (fn  Xj  =>  Xj)  Cj  where  x,  ranges  through  all  vari¬ 
ables  and  ej  ranges  through  all  function  abstractions.  For  the  proof  note 
that  since  e*  is  an  application  it  can  be  “maximally  expanded”:  either  into 
(((x  ei)  62)  •  •  •  e„)  (for  n  >  0)  in  which  case  we  know  that  p(x)  ^  0,  or  else 
into  ((((fn  y  =>  e)  ei)  62)  •  •  •  e„)  (for  n  >  0);  in  both  cases  we  prove  the 
desired  result  by  induction  on  n.  C 


Semantic  correctness 

Despite  our  lack  of  interest  in  this  analysis  let  us  nonetheless  consider  the 
possibility  of  establishing  a  subject  reduction  result;  in  the  table  below  we  put 
answers  in  parantheses  in  order  to  remind  us  that  the  analysis  is  substantially 
coarser  than  those  previously  considered. 

Proposition  A.2  The  possibility  of  proving  the  analysis  correct  with  respect 
to  the  semantics  is  given  by  the  following  table: 


AR 

s  ^ 

(yes) 

E  ^ 

(yes) 

Sa^ 

(yes) 

(no) 

Proof  (sketch).  The  formulations  of  the  subject  reduction  results  are  much 
as  in  the  proofs  of  Proposition  4.1;  we  shall  dispense  with  repeating  them  here. 

We  first  consider  the  case  of  the  substitution  based  semantics.  One  way 
to  prove  the  result  is  to  proceed  as  in  the  proof  of  the  corresponding  case 
in  Proposition  4.5.  —  A  more  “abstract”  way  of  proving  the  result  proceeds 
as  follows  where  we  must  take  care  to  restrict  all  p{x)  and  W  to  be  subsets 
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of  ret(Exp'^”).  If  an  expression  (in  the  original  syntax)  can  evaluate  into 
another  then  it  must  be  an  application  and  hence  it  must  expand  into  either 
(((rc  ei)  62)  • '  •  e„)  (for  n  >  0)  or  else  ((((fn  y  =>  e)  ei)  62)  •  •  •  e„)  (for 
n  >  0).  In  fact  the  first  case  cannot  arise  because  variables  are  not  values. 
This  leaves  us  with  the  second  case  where  it  follows  from  Fact  A.l  that  the  p 
and  W  in  question  must  state  that  all  function  abstractions  reach  everywhere; 
but  this  suffices  for  analysing  an  arbitrary  expression  since  all  constraints  are 
then  vacuously  fulfilled. 

We  next  consider  the  case  of  the  environment  based  semantics  where  we 
proceed  as  in  the  proof  of  the  corresponding  case  in  Proposition  4.1. 

The  positive  result  for  may  be  proved  as  in  the  “abstract”  way  of 

proving  above:  if  there  is  any  possibility  of  using  alpha-renaming  we 

know  by  Fact  A.l  that  the  p  and  W  in  question  must  state  that  all  function 
abstractions  reach  everywhere;  but  then  alpha-renaming  is  not  harmful. 

The  negative  result  for  may  be  obtained  as  follows:  let  Va: :  p{x)  =  0, 
W  =  {fn  X  =>  x},  p  =  [  ],  iei  =  f n  x  =>  x  and  *62  =  close  (fn  y  =>  y)  in  [  ].□ 
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Abstract 

Automata  (or  labeled  transition  systems)  are  widely  used  as  operational  models  in 
the  field  of  process  description  languages  like  CCS  [13].  There  are  however  classes 
of  formalisms  that  are  not  modelled  adequately  by  the  automata.  This  is  the  case, 
for  instance,  of  the  7r-calculus  [15,14],  an  extension  of  CCS  where  channels  can  be 
used  as  values  in  the  communications  and  new  channels  can  be  created  dynamically. 
Due  to  the  necessity  to  represent  the  creation  of  new  channels,  infinite  automata 
are  obtained  in  this  case  also  for  very  simple  agents  and  a  non-standard  definition 
of  bisimulation  is  required. 

In  this  paper  we  present  an  enhanced  version  of  automata,  called  history  de¬ 
pendent  automata,  that  are  adequate  to  represent  the  operational  semantics  of  tt- 
calculus  and  of  other  history  dependent  formalisms.  We  also  define  a  bisimulation 
equivalence  on  history  dependent  automata,  that  captures  7r-calculus  bisimulation. 
The  results  presented  here  are  discussed  in  more  detail  in  [21]. 


1  Introduction 

In  the  context  of  process  algebras  (e.g.,  Milner’s  CCS  [13]),  automata  (or  la¬ 
beled  transition  systems)  are  often  used  as  operational  models.  They  allow  for 
a  simple  representation  of  process  behavior  and  many  concepts  and  theoretical 
results  for  these  process  algebras  are  independent  from  the  particular  syntax 
of  the  languages,  and  can  be  formulated  directly  on  automata.  In  particular, 
this  is  true  for  the  behavioral  equivalences  and  preorders  which  have  been 
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defined  for  these  languages,  like  bisimulation  equivalence  [13,22]:  in  fact  they 
take  into  account  just  the  labeled  actions  an  agent  can  perform. 

Automata  are  also  important  from  an  algorithmic  point  of  view:  efficient 
and  practical  techniques  and  tools  for  verification  [9,12]  have  been  developed 
foT  finite-state  automata.  Finite  state  verification  is  successful  here,  differently 
than  in  ordinary  programming,  since  the  control  part  and  the  data  part  of 
protocols  and  hardware  components  can  be  often  cleanly  separated,  and  the 
control  part  is  usually  both  quite  complex  and  finite  state. 

There  are  classes  of  process  description  languages,  however,  whose  opera¬ 
tional  semantics  is  not  described  in  a  satisfactory  way  by  ordinary  automata. 
A  paradigmatic  example  is  provided  by  7r-calculus  [15,14].  This  calculus  can 
be  considered  as  a  foundational  calculus  for  concurrent  functional  languages, 
as  A-calculus  for  sequential  functional  languages.  In  7r-calculus  channel  names 
can  be  used  as  messages  in  the  communications,  thus  allowing  for  a  dynamic 
reconfiguration  of  process  acquaintances.  More  importantly,  7r-calculus  names 
can  model  objects  (in  the  sense  of  object  oriented  programming  [24])  and  name 
sending  thus  models  higher  order  communication  [23].  New  channels  between 
the  process  and  the  environment  can  be  created  at  run-time  and  referred  to 
in  subsequent  communications. 

The  operational  semantics  of  7r-calculus  is  given  via  a  labeled  transition 
system.  This  is  not  completely  adequate  to  deal  with  the  peculiar  features  of 
the  calculus  and  complications  arise  in  the  representation  of  the  creation  of 
new  channels.  Consider  process  p  =  (uy)  xy.q;  it  communicates  name  y  on 
channel  x  and  then  behaves  like  q.  Channel  y  is  initially  a  local,  restricted 
channel  for  process  p,  however  the  restriction  is  removed  when  the  commu¬ 
nication  takes  place,  since  it  makes  name  y  known  also  outside  the  process. 
This  communication  represents  the  creation  of  a  new  channel.  In  the  ordinary 
semantics  of  the  7r-calculus  it  is  modelled  by  means  of  an  infinite  bunch  of 

transitions  of  the  form  p  qiw/y},  where  w  is  any  name  that  is  not  already 
in  use  in  p.  This  way  to  represent  the  creation  of  new  names  has  some  dis¬ 
advantages:  first  of  all,  also  very  simple  7r-calculus  agents,  like  p,  give  rise  to 
infinite-state  and  infinite-branching  transition  systems.  Moreover,  equivalent 
processes  do  not  necessarily  have  the  same  sets  of  channel  names;  so,  there  are 
processes  q  equivalent  to  p  which  cannot  use  y  as  the  name  for  the  newly  cre¬ 
ated  channel.  Special  rules  are  hence  needed  in  the  definition  of  bisimulation, 
which  is  not  the  standard  one  for  transition  systems,  and,  as  a  consequence, 
standard  theories  and  algorithms  do  not  apply  to  TT-calculus. 

This  is  a  general  problem  for  the  class  of  history- dependent  calculi.  A 
calculus  is  history  dependent  if  the  observations  labeling  the  transitions  of 
an  agent  may  refer  to  informations  —  names  in  the  case  of  7r-calculus  — 
generated  in  previous  transitions  of  the  agent. 

In  [21]  history- dependent  automata  {HD-automata  in  brief)  are  proposed 
as  a  general  model  for  history-dependent  calculi.  As  ordinary  automata,  they 
are  composed  of  states  and  of  transitions  between  states.  To  deal  with  the 
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peculiar  problems  of  history-dependent  calculi,  however,  states  and  transition 
are  enriched  with  sets  of  local  names:  in  particular,  each  transition  can  refer 
to  the  names  associated  to  its  source  state  but  can  also  generate  new  names, 
which  can  then  appear  in  the  destination  state.  In  this  manner,  the  names  are 
not  global  and  static,  as  in  ordinary  labeled  transition  systems,  but  they  are 
explicitly  represented  within  states  and  transitions  and  can  be  dynamically 
created. 

This  permits  to  represent  adequately  the  behavior  of  history-dependent 
processes.  In  particular,  vr-calculus  agents  can  be  translated  into  HD-au- 
tomata  and  a  first  sign  of  the  adequacy  of  HD-automata  for  dealing  with 
TT-calculus  is  that  a  large  class  of  finitary  7r-calculus  agents  can  be  represented 
by  finite-state  HD-automata. 

In  [21]  a  general  definition  of  bisimulation  for  HD-automata  is  also  given. 
An  important  result  is  that  this  general  bisimulation  equates  the  HD-automata 
obtained  from  two  7r-calculus  agents  if  and  only  if  the  agents  are  bisimilar 
according  to  the  ordinary  (strong,  early)  7r-calculus  bisimilarity  relation. 

These  results  do  not  hold  only  for  the  7r-calculus:  similar  mappings  ex¬ 
ist  also  for  other  history-dependent  calculi.  In  previous  papers  [20,18,19]  we 
defined  mappings  to  HD-automata  for  CCS  with  localities  [4],  for  CCS  with 
causality  [7,6,11],  and,  to  consider  an  example  outside  the  field  of  process 
algebras,  for  the  history-preserving  semantics  of  Petri  nets  [2]. 

Papers  [20,18,19]  introduce  the  applications  of  HD-automata  without  re¬ 
sorting  to  categories.  Report  [21]  defines  HD-automata  and  HD-bisimulation 
both  in  a  set  theoretical  style  and  following  the  uniform  categorical  approach 
of  [10]  based  on  spans  of  open  maps. 

In  this  paper  we  summarize  some  of  the  results  of  [21].  In  particular,  we 
define  HD-automata  in  a  categorical  framework,  by  exploiting  a  classical  cat¬ 
egorical  definition  of  ordinary  automata.  We  also  show  that  7r-calculus  agents 
can  be  translated  into  HD-automata.  Finally,  we  introduce  HD-bisimulation 
by  applying  to  HD-automata  the  approach  of  open  maps.  We  refer  to  [21]  for 
the  proof  of  the  results  presented  here  and  for  a  deeper  study  of  the  properties 
of  HD-automata. 

2  The  TT-calculus 

The  TT-calculus  [15,14]  is  an  extension  of  CCS  in  which  channel  names  can  be 
used  as  values  in  the  communications,  i.e.,  channels  are  first-order  values.  This 
possibility  of  communicating  names  gives  to  the  vr-calculus  a  richer  expressive 
power  that  CCS:  in  fact  it  allows  to  generate  dynamically  new  channels  and  to 
change  the  interconnection  structure  of  the  processes.  The  TT-calculus  has  been 
successfully  used  to  model  object  oriented  languages  [24],  and  also  higher-order 
communications  can  be  easily  encoded  in  the  TT-calculus  [23],  thus  allowing  for 
code  migration. 

Many  versions  of  TT-calculus  have  appeared  in  the  literature.  The  TT-calculus 
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we  present  here  is  early  and  monadic,  it  was  first  introduced  in  [16],  but  we 
present  a  slightly  simplified  version,  following  in  part  the  style  proposed  in 
[23,14]  for  the  polyadic  7r-calculus. 

Let  01  be  an  infinite,  denumerable  set  of  names,  ranged  over  by  a,...,z, 
and  let  Var  be  a  finite  set  of  agent  identifiers,  denoted  by  A,B,.. the  tt- 
calculus  agents,  ranged  over  by  p,q,.. .,  are  defined  by  the  syntax 

p  ::=  0  TT.p  p\p  p+p  {ux)p  [x=y]p  A{xi,...,Xn) 
where  the  prefixes  tt  are  defined  by  the  syntax 

TT  ::=  T  xy  x{y). 

The  occurrences  of  y  in  x{y).p  and  {vy)p  are  bound;  free  names  of  agent  p  are 
defined  as  usual  and  we  denote  them  with  fn(p).  For  each  identifier  A  there  is  a 

definition  A{yi, . . . ,  pa  (with  y,  all  distinct  and  fn(pA)  ^  {vi,  yn}); 
we  assume  that,  whenever  A  is  used,  its  arity  n  is  respected.  Finally  we  require 
that  each  agent  identifier  in  pa  is  in  the  scope  of  a  prefix  (guarded  recursion). 

If  <7  :  01  — >•  01,  we  denote  with  pa  the  agent  p  whose  free  names  have 
been  replaced  according  to  substitution  a  (possibly  with  changes  in  the  bound 
names);  we  denote  with  {yi/xi  •  •  -yn/xn}  the  substitution  that  maps  xi  into 
yi  for  i  =  1, . . . ,  n  and  which  is  the  identity  on  the  other  names. 

Notice  that,  with  some  abuse  of  notation,  we  can  see  substitution  a  in 
pa  as  a  function  on  fn(p)  rather  than  on  01;  in  fact,  pa  and  pa'  coincide 
whenever  a  and  a'  coincide  on  fn(p).  So,  we  say  that  substitution  a  is  injective 
for  p  if  a  :  fn(p)  01  is  an  injective  function.  We  also  say  that  agents  p 
and  q  differ  for  a  bijective  substitution  if  there  exists  some  bijective  function 
a  :  fn(p)  f n(y)  such  that  q  =  pa. 

We  define  7r-calculus  agents  up  to  a  structural  congruence  =,  in  the  style 
of  the  Chemical  Abstract  Machine  [1].  This  structural  congruence  allows  to 
identify  all  the  agents  which  represent  essentially  the  same  system  and  which 
differ  just  for  syntactical  details;  moreover  it  simplifies  the  presentation  of  the 
operational  semantics.  The  structural  congruence  =  is  the  smallest  congruence 
that  respects  the  following  rules. 

(alpha)  (ux)  p  =  (i/y)  (p{y/a;})  if  y  ^  fn(p) 

(sum)  p+0  =  p  p+g  =  q+p  P+{q+r)  =  {p+q)+r 

(par)  p|0  =  p  p\q  =  q\p  p\{q\r)  =  {p\q)\r 

(res)  (ux)  0  =  0  (i/x)  (uy)  p  =  (uy)  (i/x)  p 

(ux)  (ply)  =  pKi'x)  q  ii  X  ^  fn(p) 

(match)  [x  =  x]p  =  p  [x  =  y]0  =  0 
By  exploiting  the  structural  congruence  =,  each  7r-calculus  agent  can  be  seen 
as  a  set  of  sequential  processes  that  act  in  parallel,  sharing  a  set  of  chan¬ 
nels,  some  of  which  are  global  (unrestricted)  whereas  some  other  are  local 
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Table  1 


Early  operational  semantics. 

(restricted).  Each  sequential  process  is  a  term  of  the  form 

s  ::=  n.p  p+p  A{xi,...,Xn) 

that  can  be  considered  as  a  “program”  describing  all  the  possible  behaviors 
of  the  sequential  process.  These  sequential  processes  are  then  connected  by 
means  of  the  operators  of  parallel  composition  and  restriction,  that  allow  to 
describe  the  structure  of  the  system  in  which  the  processes  act. 

The  actions  an  agent  can  perform  are  defined  by  the  syntax 

a  ::=  r  xy  xy  x(z) 

and  are  called  respectively  synchronization,  input,  free  output  and  bound  out¬ 
put  actions;  x  and  y  are  free  names  of  a  (fn(a)),  whereas  2:  is  a  bound  name 
(bn(Q:));  moreover  n(Q;)  =  fn(Q')  U  bn(Q!).  Name  x  is  called  the  subject  and  y 
or  z  the  object  of  the  action. 

The  transitions  for  the  early  operational  semantics  are  defined  by  the  axiom 
schemata  and  the  inference  rules  of  Table  1. 

Some  comments  on  the  syntax  and  on  the  operational  semantics  of  tt- 
calculus  are  now  in  order.  The  syntax  of  7r-calculus  is  similar  to  that  of 
CCS;  the  most  important  difference  is  in  the  prefixes.  The  output  prefix  xy.p 
specifies  not  just  the  channel  x  for  the  communication,  but  also  the  value  y 
that  is  sent  on  x;  in  the  input  prefixes  x{y).p,  name  x  represents  still  the 
channel,  whereas  y  represents  a  formal  variable  in  p,  that  is  instantiated  by 
the  effectively  received  value  when  the  input  transition  takes  place. 

The  matching  [x=y]p  represents  a  guard  for  agent  p:  agent  p  can  act  only 
if  X  and  y  coincide;  this  behavior  is  obtained  by  exploiting  the  structural 
congruence:  in  fact  [x=x]p  =  p;  no  transition  can  be  derived  from  lx=y]p  if 
x^y. 

Notice  that,  in  the  case  of  the  vr-calculus,  the  actions  a  process  can  perform 
are  different  from  the  prefixes.  This  happens  due  to  the  input  and  to  the  bound 
output.  In  the  case  of  the  input,  the  prefix  has  the  form  x{y),  while  the 
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action  has  the  form  xz;  in  fact,  y  represent  a  formal  variable,  whereas  z  is  the 
effectively  received  value  ^ .  The  bound  output  transitions  are  specific  of  the 
TT-calculus;  they  represent  the  communication  of  a  name  that  was  previously 
restricted,  i.e.,  it  corresponds  to  the  generation  of  a  new  channel  between  the 
agent  and  the  environment. 

Now  we  present  the  definition  of  the  early  bisimulation  for  the  7r-calculus. 

Definition  2.1  (early  bisimulation)  A  relation  over  agents  is  an  early 
simulation  if  whenever  p  "It  q  then: 

for  each  p  p'  with  bn(Q:)  D  f n(p,  9)  =  0  there  is  some  q  q'  such  that 
p'  n  q'. 

A  relation  IZ  is  an  early  bisimulation  if  both  71  and  7l~^  are  early  simulations. 
Two  agents  p  and  q  are  early  bisimilar,  written  p  q,  if  p  7Z  q  for  some  early 
bisimulation  71. 

As  for  CCS-like  calculi,  a  labeled  transition  system  is  used  to  give  an 
operational  semantics  to  the  7r-calculus.  However,  this  way  to  present  the  op¬ 
erational  semantics  has  some  disadvantages.  For  instance,  an  infinite  number 
of  transitions  correspond  even  to  very  simple  agents,  like  p  =  x{y).yz.O:  in 
fact,  this  agent  can  perform  an  infinite  number  of  different  input  transitions 
p  ^  wz.O,  corresponding  to  all  the  possible  choices  of  ti;  £  91.  It  is  clear  that, 
except  for  x  and  z,  which  are  the  free  names  of  p,  all  the  other  names  are 
indistinguishable  as  input  values  for  the  future  behavior  of  p.  However,  this 
fact  is  not  reflected  in  the  operational  semantics. 

Also  consider  process  q  =  (uy)  xy.y{z).0.  It  is  able  to  generate  a  new 
channel  by  communicating  name  p  in  a  bound  output.  The  creation  of  a  new 
name  is  represented  in  the  transition  system  by  means  of  an  infinite  bunch  of 

transitions  q  w{z).0,  where,  in  this  case,  w  is  any  name  different  from  x: 
the  creation  of  a  new  channel  is  modelled  by  using  all  the  names  which  are  not 
already  in  use  to  represent  it.  As  a  consequence,  the  definition  of  bisimulation 
is  not  the  ordinary  one:  in  general  two  bisimilar  process  can  have  different 
sets  free  names,  and  the  clause  “bn(Q!)  fl  f n(p,  q)  =  0”  has  to  be  added  in 
Definition  2.1  to  deal  with  those  bound  output  transitions  which  use  a  name 
that  is  used  only  in  one  of  the  two  processes.  The  presence  of  this  clause 
makes  it  difficult  to  reuse  standard  theory  and  algorithms  for  bisimulation  on 
the  TT-calculus  —  see  for  instance  [5]. 

3  History-dependent  automata 

As  explained  in  the  Introduction,  ordinary  automata  are  insufficient  to  deal 
with  history-dependent  calculi.  To  address  this  problem,  in  this  section  we 


^  This  is  not  true  in  all  the  versions  of  the  7r-calculus;  in  the  case  of  the  late  and  open 
versions,  for  instance,  also  the  input  actions  have  formal  variables  rather  than  values. 
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describe  a  richer  structure,  the  history- dependent  automata  (HD-automata  in 
brief),  which  are  obtained  by  allowing  names  to  appear  explicitly  in  states, 
transitions  and  labels.  As  we  will  see,  it  is  convenient  to  assume  that  the 
names  which  appear  in  a  state,  a  transition  or  a  label  of  a  HD-automaton  are 
local  names  and  do  not  have  a  global  identity.  In  this  way,  for  instance,  a 
single  state  of  the  HD-automaton  can  be  used  to  represent  all  the  states  of 
a  system  that  differ  just  for  a  bijective  renaming.  In  this  way,  however,  each 
transition  is  required  to  represent  explicitly  the  correspondences  between  the 
names  of  source,  target  and  label. 

In  this  section  we  show  that  HD-automata  can  be  defined  in  a  categor¬ 
ical  framework  by  extending  the  classical  categorical  definition  of  ordinary 
automata. 

An  ordinary  automaton  can  be  defined  as  a  diagram 

d 

in  the  category  Set  of  sets.  Sets  Q,  T  and  L  represent  respectively  the  states, 
the  transitions  and  the  labels  of  the  automaton.  Functions  s,  d  and  I  associate 
to  each  transition  respectively  its  source,  its  destination  state  and  its  label.  If 
t  G  T  is  such  that  s{t)  —  q,  d{t)  =  g'  and  l{t)  =  A,  then  we  write  in  brief 

t :  g  A-  g'.  The  initial  state  of  the  automaton  is  designated  by  i{*). 

Given  two  automata  A\  and  A2  on  the  same  set  L  of  labels,  a  morphism 
m  :  Ai  A2  is  a.  pair  of  arrows  mq  :  Qi  Q2  and  mr  :  Ti  T2  that 
respect  sources,  destinations,  labels,  and  initial  state,  i.e.,  such  that  the  two 
overlapped  diagrams 


Si 


di 


commute  in  the  obvious  way. 

The  category  Autx,  of  the  automata  on  labels  L  is  defined  by  using  au¬ 
tomata  with  labels  L  as  objects  and  morphisms  between  such  automata  as 
arrows;  identity  arrow  and  composition  between  arrows  are  defined  in  the 
obvious  way. 

HD-automata  can  be  defined  in  a  similar  way:  we  have  just  to  replace  the 
category  Set  with  a  category  of  named  sets. 

Definition  3.1  (named  sets)  A  named  set  E  is  a  set  denoted  by  E,  and  a 
family  of  name  sets  indexed  by  E,  namely  {E[e]  G  Set}eeE  (i-e.,  E[-]  is  a  map 
form  E  to  Set). 

Given  two  named  sets  E  and  E',  a  named  function  m  :  E  — >  E'  is  a  function 
on  the  sets  m  '.  E  E'  and  a  family  of  name  embeddings  (i.e.,  of  injective 
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functions)  indexed  by  m,  namely  {m[e,  e']  :  E'[e'] '— >•  E[e]}(e,e')em- 

E  3  e  Ef. 


E'  3  e' 


e] 

m[e 

E'[e'| 


A  named  set  E  is  finitely  named  if  E[e]  is  finite  for  each  e  €  £'.  A  named  set 
E  is  finite  if  it  is  finitely  named  and  set  E  is  finite. 

The  category  NSet  of  named  sets  has  named  sets  as  objects  and  named 
functions  as  arrows;  in  particular: 

•  if  E  is  a  named  set,  then  ide  is  the  named  function  such  that,  for  each  e  G  JS, 
idE{e)  =  e  and  idE[e,e]  =  idE[e]; 

•  if  m  :  El  — >  E2  and  m' :  E2  — E3  are  two  named  functions,  then  m;  m' :  Ei  -> 
E3  is  the  named  function  such  that,  for  each  e  E  Ei,  m;m'(e)  =  m'(m(e)) 
and,  if  m(e)  =  d  and  m'(e')  =  e"  then  m;  m'[e,  e"\  =  m'[e',  e"];  m[e,  e']. 

Definition  3.2  (HD-automata)  Let  Start  be  the  named  set  with  *  as  sin¬ 
gleton  element  and  Start[*]  =  91.  A  HD-automaton  is  a  diagram 

L  T  Q  Start 

d 

in  the  category  NSet  of  named  sets. 

A  HD-automaton  is  finitely  named  if  L,  Q  and  T  are  finitely  named;  it  is  finite 
if,  in  addition,  Q  and  T  are  finite. 

Given  two  HD-automata  Ai  and  A2  on  the  same  named  set  L  of  labels,  a 
morphism  m  :  Ai  — >  A2  is  a  pair  of  arrows  mg  :  Qi  — Q2  and  :  Ti  — >  T2 
that  respects  sources,  destinations,  labels,  and  initial  state,  i.e.,  such  that  the 
two  overlapped  diagrams 


Sl 


d2 


commute  in  the  obvious  way. 

The  category  HDl  of  the  HD-automata  on  labels  L  is  defined  as  the  full 
subcategory  of  HD  whose  objects  have  L  as  the  set  of  labels  and  respect  the 
following  condition: 

T[t]  =  cod(s[t,  s{t)])  U  cod(l[f,  /(<)])  for  each  t  eT. 

Let  t  be  a  transition  of  a  HD-automaton  such  that  s{t)  =  q,  d{t)  =  q'  and 

i(t)  =  A  (in  this  case  we  write  in  brief  t  :  q  (f).  Then  s[t,  g]  embeds  the 
names  of  q  into  the  names  of  t,  whereas  d[t,  q']  embeds  the  names  of  q'  into  the 
names  of  t;  in  this  way,  a  partial  correspondence  is  defined  between  the  names 
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of  the  source  state  and  those  of  the  target;  the  names  which  appear  in  the 
source  and  not  in  the  target  are  discarded,  or  forgotten,  during  the  transitions, 
whereas  the  names  that  appear  in  the  target  but  not  in  the  source  are  created 
during  the  transition.  Condition  “T[t]  =  cod(s[t,  s(t)])  U  cod(l[t,  i(t)])”  corre¬ 
sponds  to  require  that  all  the  names  that  are  created  in  the  transition  must 
appear  explicitly  in  the  label  (name  discarding,  instead,  can  appear  silently). 

The  initial  state  qo  of  a  HD-automaton  is  designated  by  i{*),  whereas 
i[*,  9o]  is  the  initial  embedding  that  maps  the  names  of  the  initial  state  into 
the  set  Ot  of  global  names. 

3.1  Well-sorted  HD-automata 

The  HD-automata  we  have  defined  above  are  satisfactory  for  representing  the 
operational  semantics  of  many  history  dependent  formalisms,  like  CCS  with 
localities  [20]  and  Petri  nets  with  history-preserving  bisimulation  [19].  They 
are  not  completely  adequate  for  the  7r-calculus. 

In  fact,  let  p(a,  b,  c)  and  q(a,  b)  be  equivalent  7r-calculus  agents  with  differ¬ 
ent  sets  of  free  names  ^  and  suppose  the  two  agents  perform  a  bound  output. 
According  to  Definition  2.1,  in  checking  bisimilarity  we  require  that  the  object 
of  the  bound  output  is  a  new  name  for  both  agents.  On  the  HD-automata  this 
can  be  achieved  by  representing  the  bound  output  with  an  unique  transition 
that  introduces  a  new  name. 

If  the  two  agents  perform  an  input,  however,  all  the  names  must  be  con¬ 
sidered  as  possible  input  values.  To  represent  the  input  on  a  HD-automaton, 
we  have  to  consider  a  transition  for  each  of  the  names  which  are  present  in  the 
source  state,  and  a  transition  corresponding  to  the  input  of  a  fresh  name.  In 
both  the  HD-automata  corresponding  to  p  and  q,  hence,  there  are  transitions 
corresponding  to  the  input  of  names  a  and  b  and  to  the  input  of  a  fresh  name. 
The  transition  for  name  c  appears  only  in  the  HD-automaton  of  p,  since  c  is 
not  free  in  q:  this  transition  of  p  is  matched  in  q  by  the  transition  for  the  fresh 
name. 

This  shows  that  the  objects  of  bound  outputs  and  of  inputs  have  different 
meanings:  in  the  case  of  bound  outputs  they  are  new  names,  whereas  the 
objects  of  inputs  are  either  already  present  in  the  source  state  or  universal 
names  (i.e.,  they  represent  all  the  other  names,  including  the  names  which 
are  free  only  in  the  other  agent).  In  the  HD-automata,  however,  there  is 
only  one  way  to  introduce  fresh  names  in  a  transition;  so  we  need  to  add  a 
new  component  to  the  HD-automata  to  distinguish  between  bound-output- 
like  transitions  and  fresh-input-like  transitions.  This  new  component,  called 
sorting.,  allows  to  distinguish  the  names  of  a  label  that  must  appear  in  the 
source  (the  old  names),  those  that  cannot  appear  in  the  source  (the  new 
names)  and  those  that  may  appear  in  the  source  (the  both  names). 

®  This  can  be  easily  obtained,  for  instance  by  getting  p(o,  b,  c)  =  q{a,  b)  +  (vx)  xc.O,  where 
the  component  (t/x)  xc.O  is  deadlocked. 


9 


Montanari  and  Pistore 


Definition  3.3  (well-sorted  HD-automata)  Let  L  be  a  named  set  of  la¬ 
bels.  A  sorting  F  for  L  associates  to  each  label  A  €  L  a  function  Fa  :  L[A] 
{new,  old,  both}. 

The  category  HDt.r  of  the  well-sorted  HD-automata  on  labels  L  and  sorting 
F  is  defined  as  the  full  subcategory  of  HDl  whose  objects  respect  following 
condition: 

for  each  t  gT  and  n  €  L[/(t)],  if  l[t,  l{t)]{n)  €  cod(s[t,  s(t)])  then  Fj(t)(n)  7^ 
new  and  if  \[t,l(t)]{n)  ^  cod(s[t,  s(t)])  then  Fj(t)(n)  ^  old. 

According  to  the  previous  considerations,  the  names  of  a  transition  t :  q  q' 
are  classified  as  follows: 

•  T[t]new  =  {n  I  n'  €  L[A],  FA(n')  =  new,  \[t,  A](n')  =  n}  are  the  new  names  of 
transition  t,  i.e.,  the  names  which  correspond  to  names  of  the  label  of  sort 
new; 

•  T[t]src  =  cod(s[t,  9])  are  the  names  of  transition  t  that  are  already  present 
in  the  source  state; 

•  T[t]univ  =  T[t]both  \  T[i]src  are  the  universal  names  of  transition  t,  i.e.,  the 
names  which  correspond  to  names  of  the  label  of  sort  both  and  which  are 
not  present  in  the  source  state. 

Notice  that  T[t]src,  T[t]nev  and  T[t]univ  are  a  partition  of  T[t],  i.e.,  they  are 
disjoint  and  their  union  contains  all  the  names  of  t. 

4  Representing  7r-calculus  agents  as  HD-automata 

We  are  interested  in  the  representation  of  7r-calculus  agents  as  HD-automata. 
First  we  define  the  named  set  of  labels  for  this  language:  we  have  to 
distinguish  between  synchronizations,  inputs,  free  outputs  and  bound  outputs. 
Thus  the  set  of  labels  is 

Ljr  =  {tau,  in,  in2,  out,  out2,  bout} 

where  in2  and  out2  are  used  when  subject  and  object  names  of  inputs  or  free 
outputs  coincide  (these  special  labels  are  necessary,  since  the  function  from 
the  names  associated  to  a  label  into  the  names  associated  to  a  transition  must 
be  injective).  No  name  is  associated  to  tau,  one  name  (n)  is  associated  to  in2 
and  out 2  and  two  names  (ngub  and  riobj)  are  associated  to  in,  out  and  bout. 
The  sorting  F^  on  is  defined  as  follows: 


A 

tau 

in 

in2 

out 

out  2 

bout 

— 

^obj 

n 

^sub 

^obj 

n 

^sub 

^obj 

— 

both 

old 

old 

old 

old 

old 

new 

This  means  that  the  subject  names  of  the  labels  must  be  old  names,  whereas 
the  object  names  must  be  old  in  the  case  of  free  output,  new  in  the  case  of 
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bound  output  and  can  be  either  old  or  new  in  the  case  of  input. 

To  associate  a  HD-automaton  to  a  7r-calculus  agent,  we  have  to  represent 
the  derivatives  of  the  agent  as  states  of  the  automaton  and  their  transitions  as 
transitions  in  the  HD-automaton;  the  names  corresponding  to  a  state  are  the 
free  names  of  the  corresponding  agent,  the  names  corresponding  to  a  transition 
are  the  free  names  of  the  source  state  plus  the  new  names  (if  any)  appearing 
in  the  label  of  the  transition.  A  label  of  L„  is  associated  to  each  transition  in 
the  obvious  way. 

This  naive  construction  can  be  improved  to  obtain  more  compact  HD- 
automata.  Consider  the  agent  p  =  x{z).q{x,y,z);  it  can  perform  an  infinite 
number  of  input  transitions,  corresponding  to  different  received  names.  In 
the  context  of  HD-automata,  however,  due  to  the  local  nature  of  names,  the 
transitions  of  p  corresponding  to  the  input  of  all  the  names  different  from 
X  and  y  are  indistinguishable;  so  it  is  sufficient  to  consider  just  three  input 
transitions  for  p,  i.e.,  the  inputs  of  names  x  and  y,  and  the  input  of  one 
representative  of  the  fresh  names. 

Similarly,  it  is  sufficient  to  consider  just  one  bound  output,  whose  extruded 
name  is  the  representative  of  the  names  not  appearing  in  the  agent;  finally, 
all  the  T  and  the  free  output  transitions  have  to  be  considered. 

According  to  the  following  definition  we  choose  to  use  the  first  name  which 
does  not  appear  free  in  p  —  namely  min(fn  \  fn(p))  —  as  representative  for 
the  input  and  bound  output  transitions  of  p. 

Definition  4.1  (representative  transitions)  A  7r-calculus  transition  t  : 
p  9  is  a  representative  transition  if  n(Q;)  C  fn(p)  U  {min(fn  \  fn(p))}. 

The  following  lemma  shows  that  the  representative  transitions  express,  up 
to  o-conversion,  all  the  behaviors  of  an  agent. 

Lemma  4.2  Let  t  :  p  q,  with  a  =  ax  (resp.  a  =  a(x)J,  be  a  non¬ 
representative  n-calculus  transition.  Then  there  is  some  representative  transi¬ 
tion  t'  :p  ^  q' ,  with  a'  =  ay  (resp.  o'  =  ^{y))>  such  that  q'  =  q{y/x  x/y}. 

If  only  representative  transitions  are  used  when  building  a  HD-automaton 
from  a  7r-calculus  agent,  the  obtained  HD-automaton  is  finite-branching  (i.e., 
with  a  finite  set  of  transitions  from  each  state  of  the  automaton). 

Another  advantage  of  using  local  names  is  that  two  agents  differing  only 
for  a  bijective  substitution  can  be  collapsed  in  the  same  state  in  the  HD- 
automaton;  we  assume  to  have  a  function  norm  that,  given  an  agent  p,  returns 
a  pair  {q,  a)  =  norm(p),  where  q  is  the  representative  of  the  class  of  agents  dif¬ 
fering  from  p  for  bijective  substitutions  and  a  :  fn{q)  ->  fn(p)  is  the  bijective 
substitution  such  that  p  =  qa. 

Definition  4.3  (from  7r-calculus  agents  to  HD-automata)  The  HD- 
automaton  Ap  corresponding  to  a  vr-calculus  agent  p  is  defined  by  the  following 
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a 

T 

xy 

XX 

xy 

XX 

x{y) 

A 

tau 

in 

in2 

out 

out  2 

bout 

n  e  L[A] 

— 

^sub 

^obj 

n 

^sub 

^obj 

n 

^sub 

^obj 

K{n) 

— 

X 

y 

X 

X 

y 

X 

X 

y 

Table  2 

Relations  between  7r-calculus  labels  and  labels  of  HD-automata. 


rules: 

•  if  nonn(p)  =  {j/,  a')  then: 

•  p'  eQ  is  the  initial  state  and  Q[p']  =  fn(p'); 

•  a'  is  the  initial  embedding; 

•  if  q  e  Q,  t  :  q  q'  is  &  representative  transition  and  norm(g')  =  {q",cr), 
then: 

•  q"  eQ  and  Q[q"]  =  fn(g"); 

■  teT  and  T[t]  =  fn{q)  U  bn(Q:); 

•  s{t)  =  q,  d{t)  =  q",  s[t,  q]  =  idf„(,)  and  d[i,  q"]  =  a; 

.  1(f)  =  X  and  l[t,  A]  =  K  are  defined  as  in  Table  2. 

Lemma  4.4  For  every  'K-calculus  agent  p,  the  HD-automaton  A.p  is  well- 
sorted  for  labels  and  sorting  F^r- 

For  each  7r-calculus  agent  p,  the  HD-automaton  Ap  is  obviously  finitely 
named.  Now  we  will  identify  a  class  of  agents  that  generate  a  finite  HD- 
automaton.  This  is  the  class  of  finitary  7r-calculus  agents,  which  is  defined 
like  the  corresponding  class  of  CCS  agents. 

Definition  4.5  (finitary  agents)  The  degree  of  parallelism  deg(p)  of  a  ir- 
calculus  agent  p  is  defined  as  follows: 

deg(O)  =  0  deg(/x.p)  =  1 

deg{{ua)p)  =  deg(p)  deg(plg)  =  deg(p)  H-  deg(g) 

deg(p-l-g)  =  1  deg([a;=p]p)  =  deg(p) 

deg(A)  =  1 

A  TT-calculus  agent  p  is  finitary  if  max{deg(p')  |  p  ^  p'}  <  oo. 

Theorem  4.6  Let  p  be  a  finitary  ir-calculus  agent.  Then  the  HD-automaton 
Ap  is  finite. 

An  important  class  of  finitary  agents  which  can  be  characterized  syntac¬ 
tically  is  the  class  of  the  agents  with  finite  control,  i.e.,  the  agents  without 
parallel  composition  in  the  body  of  recursive  definitions.  In  this  case,  after  an 
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initialization  phase  during  which  a  finite  set  of  processes  acting  in  parallel  is 
created,  no  new  processes  can  be  generated. 

5  Bisimulation  for  HD-automata 

In  this  section  we  introduce  a  notion  of  bisimulation  on  HD-automata  and  give 
some  basic  properties  of  this  bisimulation.  We  also  show  that  the  definition 
of  bisimulation  on  7r-calculus  agents  is  captured  exactly  by  the  bisimulation 
on  HD-automata. 


5.1  Open  maps  and  bisimulations 

Consider  a  morphism  m  :  ->  A2  in  the  category  of  automata.  Relation 

^  =  {{91,92)  e  Qi  X  Q2  I  92  =  wg(9i)} 

is  a  simulation  for  Ax  and  A2.  In  fact,  assume  qi  %  q2  and  h  :  qi  q[]  then 

we  have  *2  :  92  ^  92  and  q[  Tl  q'2  by  taking  (fi'llq2-  Moreover  901  9o2- 

So,  a  morphism  m  :  Ai  A2  expresses  the  fact  that  all  the  transitions 
of  Ai  can  be  simulated  in  A2,  starting  from  the  initial  states.  In  general, 
however,  it  is  not  true  that  all  the  transitions  of  A2  can  be  simulated  in  Ai. 

However,  it  is  possible  to  define  a  particular  class  of  “bisimulation”  mor- 
phisms,  such  that  the  existence  of  such  a  morphism  from  Ai  to  A2  guarantees 
not  only  that  the  transitions  of  Ai  can  be  adequately  simulated  in  A2  but 
also  the  converse;  i.e.,  the  existence  of  a  “bisimulation”  morphism  guarantees 
that  Ai  and  A2  are  bisimilar.  In  general,  it  is  not  true  the  converse,  i.e.,  there 
exist  bisimilar  automata  Ai  and  A2  such  that  no  “bisimulation”  morphism 
(nor  generic  morphisms)  can  be  found  between  them.  However,  whenever  two 
automata  Ax  and  A2  are  bisimilar,  it  is  possible  to  find  a  common  predecessor 
A  and  a  span  of  “bisimulation”  morphisms  mx  :  A  Ax  and  m2  :  A  A2 
between  them. 

A 

Ax  .<42 

This  class  of  “bisimulation”  morphisms  have  been  defined  in  various  man¬ 
ner  in  the  literature,  and  different  names  have  been  given  to  them.  Here  we 
just  consider  the  approach  of  open  maps  [10],  that  it  is  general  enough  to  be 
applied  not  only  to  automata,  but  also  to  other  models  of  concurrency,  like 
Petri  nets  and  event  structures. 

Assume  a  category  M  of  models.  Let  E  be  the  subcategory  of  M  whose 
objects  are  the  experiments  that  can  be  executed  on  M  and  whose  arrows 
express  how  the  experiments  can  be  extended.  If  X  is  an  object  of  E  and  M 
is  an  object  of  M,  an  arrow  x  :  X  M  oiM  represents  the  execution  of  the 
experiment  X  in  the  model  M. 
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Consider  an  arrow  m  :  A/  — >■  iV  in  M.  We  can  see  this  arrow  as  a  simulation 
of  model  M  in  model  N.  So,  correctly,  if  an  experiment  X  can  be  executed 
in  M  (there  exists  an  arrow  x  :  X  M)  and  N  can  simulate  M  (there  exists 
an  arrow  m:  M  N)  then  the  experiment  X  can  be  executed  in  N  (via  the 
arrow  x;  m  :  X  — >  N). 

Suppose  now  to  extend  the  experiment  X  to  an  experiment  Y  (via  an 
arrow  /  :  X  — >•  F  in  E)  and  that  an  arrow  y  :  Y  N  exists  such  that  the 
following  diagram  commutes  in  M. 


(1) 


X^^M 


f 


Y 


y 


r 

N 


This  means  that  the  execution  of  the  experiment  X  in  N  (via  x;  m)  can 
be  extended  to  an  execution  of  the  experiment  Y  in  N  (via  y). 

This  does  not  imply  in  general  that  also  the  execution  of  X  in  M  can  be 
extended  to  an  execution  of  F  in  M  (which  equates  y  via  m)  but  we  can  make 
this  sure  by  requiring  that  there  is  an  arrow  y'  such  that  the  diagram 


commutes.  Given  m,  if  for  each  commuting  diagram  (1)  there  is  an  arrow  y' 
such  that  also  (2)  commutes,  we  say  that  m  is  an  E-open  map. 

It  is  easy  to  check  that  the  open  maps  form  a  subcategory  of  M  (i.e., 
identities  are  open  and  open  maps  are  closed  for  composition). 


Definition  5.1  (open  bisimulation)  We  say  that  two  objects  Mi  and  M2 
of  M  are  open-bisimilar  with  respect  to  E  if  and  only  if  there  is  a  span  of 
E-open  maps  mi,  m2. 


M 

»7i^  \m2 


Ml 


Mo 


In  [10]  it  is  shown  that,  if  the  category  Aut^  is  used  as  the  category  of 
the  models  and  the  full  subcategory  Brani,  of  the  branches  (i.e.,  of  those 
finite  automata  which  consist  of  a  linear  sequence  of  transitions)  is  used  as 
the  category  of  experiments,  then  two  automata  are  open-bisimilar  if  and  only 
if  they  are  bisimilar  according  to  the  classical  definition. 


5.2  Application  to  the  HD-automata 

In  the  case  of  HD-automata,  an  experiment  is  a  finite  sequences  of  transi¬ 
tions  and  an  extended  experiment  can  be  obtained  by  adding  new  transitions. 
Moreover,  we  require  that  no  name  is  forgotten  during  an  experiment,  since 
this  models  the  idea  that  the  observer  can  remember  all  the  names  previously 
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used  in  the  experiment.  However,  this  is  not  a  crucial  point  for  the  validity  of 
Theorem  5.4. 

Definition  5.2  (category  of  HD-experiments)  A  HD-automaton  X  is  a 
HD- experiment  if: 

•  Q  =  {qo,  9i,  •  -  • ,  Qn}  are  the  states  and  T  =  {<i, . . . ,  are  the  transitions, 
and  s(fi)  =  Qi-i  and  d{ti)  =  qi; 

•  for  all  t  eT,  d[t,  d{t)]  :  Q[d(t)]  '->•  T[t]  is  bijective. 

A  morphism  (mq,  mr)  :  X  ^  X'  is  name  preserving  ii  mg  and  mj  are  bijections 
on  the  names,  i.e.,  mQ[g,mQ(g)]  is  a  bijection  between  Q'[mQ(9)]  and  Qfg]  for 
all  q  £Q,  and  similarly  for  mr- 

The  category  Exp  of  HD-experiments  is  the  subcategory  of  HD  with  HD- 
experiments  as  objects  and  name  preserving  morphisms  as  arrows. 

Category  ExPl  p  is  the  full  subcategory  of  Exp  whose  objects  are  HDL,r- 
automata. 

Now  we  can  apply  the  general  definition  of  open-bisimilarity  in  our  case. 

Definition  5.3  (HD-bisimilarity)  Two  well-sorted  HD-automata  A  and  ® 
on  the  same  labels  L  and  sorting  F  are  HD-bisimilar,  written  A  ~  if  they 
are  open-bisimilar  w.r.t.  experiments  Expl  p. 

The  definition  of  HD-bisimilarity  can  be  applied  also  in  the  case  of  HD- 
automata  obtained  from  7r-calculus  agents.  The  induced  equivalence  on  the 
agents  coincides  exactly  with  the  strong,  early  bisimilarity  relation 

Theorem  5.4  Let  pi  and  p2  be  'k- calculus  agents.  Then  p\  P2  iff  Apj  ~ 
Ap2- 

It  is  also  possible  to  give  an  explicit  definition  of  HD-bisimulation,  in  terms 
of  relations  on  the  states,  rather  that  in  terms  of  bisimulation  morphisms.  The 
explicit  definition  is  reported  in  Appendix  A. 


6  Concluding  remarks 

In  this  paper  we  have  briefly  described  history  dependent  automata,  an  oper¬ 
ational  model  adequate  to  deal  with  history  dependent  calculi.  In  particular, 
we  have  represented  7r-calculus  agents  via  HD-automata  and  strong,  early  tt- 
calculus  bisimilarity  via  a  general  definition  of  bisimulation  equivalence  on 
HD-automata.  All  these  results  will  appear  in  more  detail  in  [21]. 

We  want  to  stress  that  HD-automata  can  be  applied  successfully  also  to 
the  late  semantics  of  7r-calculus  (only  the  translation  of  Definition  4.3  has  to 
be  changed)  or  to  other  examples  of  history  dependent  calculi,  as  for  instance 
CCS  with  localities  [4,20]  or  with  causality  [6,18].  It  is  also  possible  to  define 
a  weak  HD-bisimulation  that  applies  to  all  these  cases.  Also,  HD-automata 
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can  be  applied  to  formalisms  outside  the  field  of  process  algebras;  this  is  the 
case  for  the  history-preserving  semantics  of  Petri  nets  [2,19]- 

HD-automata  are  very  promising  for  the  development  of  automatic  verifica¬ 
tion  tools  for  history  dependent  calculi.  In  fact,  HD-automata  can  be  used  as  a 
common  format  in  which  various  history-dependent  calculi  can  be  translated, 
so  that  general  algorithms  on  HD-automata  can  be  re-used  for  all  these  calculi. 
We  are  developing  a  verification  environment  which  is  based  on  the  approach 
above.  The  environment  provides  a  number  of  front  ends  translating  the  dif¬ 
ferent  history  dependent  formalisms  into  HD-automata,  and  a  set  of  tools  to 
edit,  visualize,  compose  and  check  for  equivalence  the  obtained  HD-automata. 
It  is  also  possible  to  associate  ordinary  automata  to  the  HD-automata,  in  such 
a  way  that  bisimilar  HD-automata  are  mapped  into  bisimilar  automata,  and 
finite  HD-automata  are  mapped  into  finite  automata.  In  this  way,  classical 
algorithms  and  tools  for  ordinary  automata  [3]  can  be  re-used.  A  preliminary 
report  on  the  development  of  the  tool  appeared  in  [8]. 
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A  Explicit  definition  of  HD-bisimulation 

Here  we  want  to  give  an  explicit  definition  of  bisimulation  on  HD-automata 
which  is  equivalent  to  the  one  given  in  Definition  5.3  by  exploiting  the  open 
maps.  This  definition  is  less  satisfactory  than  the  one  given  via  open  maps, 
since,  as  we  will  see,  it  has  to  deal  explicitly  with  the  different  sorts  of  names 
that  appear  in  a  transition.  However,  the  explicit  definition  makes  it  clear  that 
the  bisimulation  of  two  HD-automata  can  be  effectively  decided  whenever  the 
two  HD-automata  are  finite. 
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Due  to  the  private  nature  of  the  names  appearing  in  the  states  of  HD- 
automata,  bisimulations  cannot  simply  be  relations  on  the  states;  they  must 
also  deal  with  name  correspondences:  a  HD-bisimulation  is  a  set  of  triples 
of  the  form  {qi,S,q2)  where  qi  and  q2  are  states  of  the  automata  and  5  is  a 
partial  bijection  between  the  names  of  the  states.  The  bijection  is  partial  since 
we  allow  for  equivalent  states  with  different  numbers  of  names  (for  instance, 
equivalent  vr-calculus  agents  can  have  different  sets  of  free  names).  In  what 
follows,  we  represent  a  partial  bijection  f  from  set  A  to  set  B  with  /  :  A  B. 

Suppose  that  we  want  to  check  if  states  qi  and  q2  are  (strongly)  bisimilar 
via  the  partial  bijection  5  :  Q[qi\  ^  Q[92]  and  suppose  that  qi  can  perform  a 
transition  ti  :  qi  ^  q'l-  We  assume  for  the  moment  that  all  the  names  of  the 

label  A  are  of  sorts  old  or  new.  Then  we  have  to  find  a  transition  t2  '•  q2  92 
that  matches  ti,  i.e.,  not  only  the  two  transitions  must  have  the  same  label, 
but  also  the  names  associated  to  the  labels  must  be  used  consistently.  This 
means  that: 

a)  if  a  name  n  of  the  label  is  of  sort  old,  then  the  corresponding  names  in  the 
source  states  qi  and  q2  must  be  in  correspondence  by  S  (such  names  surely 
exist  in  and  q2,  if  the  HD-automata  are  well-sorted); 

b)  if  a  name  n  of  the  label  is  of  sort  new,  then  the  corresponding  names  in 
the  transitions  ti  and  t2  are  put  in  correspondence  (if  the  HD-automata  are 
well-sorted,  no  names  corresponding  to  n  appear  in  the  source  states). 

This  behavior  is  obtained  by  requiring  that  a  partial  bijection  C  :  T[ti] 
nh]  exists  such  that:  i)  C  coincides  with  S  if  restricted  to  the  names  of 
the  source  states  (obviously,  via  the  embeddings  s[ti,9i]  and  s[t2)92])j  H)  the 
names  associated  to  the  labels  are  the  same,  via  C?  aiid  Hi)  the  destination 
states  gi  and  gj  bisimilar  via  a  partial  bijection  S'  which  is  compatible 
with  C  (he.,  if  two  names  are  related  by  5'  in  the  destination  states,  then  the 
corresponding  names  in  the  transitions  are  related  by  ^). 

The  situation  is  more  complex  if  a  name  n  of  the  label  A  is  of  sort  both. 
We  can  distinguish  three  more  cases: 

c)  the  name  ni  in  ti  corresponding  to  n  is  already  present  in  gi  and  is  asso¬ 
ciated  via  S'  to  a  name  of  g2;  in  this  case  a  matching  transition  <2  from  g2 
must  use  for  n  this  associated  name; 

d)  the  name  ni  in  ti  corresponding  to  n  is  already  present  in  gi  and  it  is  not 
associated  via  ^  to  a  name  of  g2;  in  this  case  ti  must  be  matched  by  a 
transition  <2  from  g2  which  uses  an  universal  name  for  n;  the  meaning  of 
this  is  that  name  ni  is  handled  as  a  special  case  in  state  gi,  but  is  handled 
by  the  default  transition  in  g2; 

e)  the  name  ni  in  fi  corresponding  to  n  is  not  already  present  in  gi  (i.e.,  ni  is 
an  universal  name);  in  this  case  we  require  that  ti  is  matched: 

el)  by  a  transition  from  g2  which  uses  an  universal  name  for  n  (the  two  uni¬ 
versal  names  are  put  in  correspondence),  and 
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e2)  for  each  name  n2  of  92  not  appearing  (via  5)  in  qi,  by  a  transition  from 
q2  that  uses  n2  for  n  (in  this  case,  a  new  correspondence  is  set  for  rii  and 
n2);  the  meaning  of  this  is  that  the  default  transition  in  qi  must  match 
also  the  special  cases  of  92  which  are  not  contemplated  by  qi. 

This  more  complex  behavior  is  obtained  by  requiring  that,  for  each  transition 
h  ■  Qi  ^  Qi  and  for  each  possible  partial  bijection  ^  between  the  universal 
names  of  t2  and  the  names  of  q2  which  do  not  already  correspond  to  names  of 
qi,  there  is  some  transition  t2  :  q2  ^2  some  partial  bijection  C  :  T[ti]  ^ 
T[t2]  extending  ^',s[t2,q2]  such  that  i)  C  satisfies  the  rules  a-e)  above"* ;  ii)  the 
names  associated  to  the  labels  are  the  same,  via  C,  and  iii)  the  destination 
states  q[  and  q^  are  bisimilar  via  a  partial  bijection  5'  which  is  compatible 
with  C-  Notice  that  to  a  name  of  ti  can  correspond  no  name  of  <2  via  C,  if  no 
name  is  associated  to  it  via  5  and  the  name  does  not  appear  in  the  label. 

Definition  A.l  (HD-bisimulation)  Let  A\  and  A2  be  two  HD-automata 
in  HDL,r-  A  HD-simulation  for  Ai  and  A2  is  a  set  of  triples  71  C  {(91, 5, 92)  I 
qi  G  Qu  92  e  Q2,  :  Qi[9i]  ^  02(92]}  such  that,  whenever  (91,5,92)  €  71 

then: 

for  each  :  91  9i  in  A\  and  for  each  ^  :  Ti[ti]univ  ^  02(92]  such 
that  cod(^)  n  cod(5)  =  0,  there  exist  some  t2  :  92  92  in  A2  and  some 

C  •  Ti(ti]  ^  T2(t2]  such  that: 

•  5  =  Si(ti,gi];C;S2[t2,92] 

•  ^  =  ClTi[ti]univ;S2(^2,92]“^ 

•  li(ii,A];C  =  12(^2,  A]; 

•  (9i,  5',  92)  ^  where  5'  C  di[ti,  gj];  C;  d2(t2, 92] 

A  HD-bisimulation  for  Ai  and  A2  is  a  set  of  triples  72.  such  that  72  is  a  HD- 
simulation  for  A\  and  A2  and  72~*  =  {(92, 5“*,  91)  |  (91,5,52)  ^  is  a 
HD-simulations  for  A2  and  Ai. 

A  HD-bisimulation  on  for  A  is  a  HD-bisimulation  for  A  and  A. 

The  HD-automata  Ai  and  A2  are  (strongly)  HD-bisimilar  (written  Ai  A2)  if 
there  exists  some  HD-bisimulation  for  Ai  and  A2  such  that  (*i(*),  5,  i2(*))  ^ 
for  5  C  ii(*,ii(=t=)];ii[*,ii(*)]“*. 

Theorem  A. 2  Two  HD-automata  are  bisimilar  according  to  Definition  5.3 
iff  they  are  bisimilar  according  to  Definition  A.l. 


*  For  rule  e):  let  ni  be  an  universal  name  of  ti;  if  ^(ni)  =  n2  €  0(52]  then  ni  must  be 
matched  by  n2  (case  e2);  if  ^(ni)  is  undefined,  an  universal  name  of  f2  must  match  ni  (case 
el). 
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Abstract 

The  syntax  and  semantics  of  actors  and  7r-agents  is  first  defined  separately,  using 
a  uniform,  “unbiased”  approach.  New  coordination  primitives  are  then  added  to 
the  union  of  the  two  calculi  which  allow  actors  and  7r-agents  to  cooperate. 


1  Modeling  Actors  and  Agents 

The  syntax  and  semantics  of  actors  and  7r-agents  are  first  defined  separately, 
using  a  uniform,  “unbiased”  approach.  Since  we  aim  at  modeling  concurrent 
distributed  systems,  and  thus  we  are  interested  in  asynchronous  behavior,  we 
choose  for  comparison  with  actors  an  asynchronous  version  of  the  7r-calculus. 

In  the  paper,  the  behavior  of  both  actors  and  7r-agents  is  defined  by  certain 
logic  sequents  called  tiles.  A  tile  is  a  rewrite  rule  which  describes  a  possible 
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evolution  of  a  part  s  of  the  system  which  is  matched  by  it.  In  addition,  a 
tile  also  describes  the  evolution  of  the  interfaces  of  s  with  the  rest  of  the  sys¬ 
tem.  Thus  two  parts  s  and  s'  sharing  an  interface  can  be  rewritten  only  by 
tiles  which  agree  on  the  evolution  of  the  common  interface.  This  restriction 
introduces  a  powerful  notion  of  synchronization  ^  among  tiles,  and  also  makes 
possible  to  see  the  synchronization  of  two  tiles  as  a  (larger)  tile.  Eventually, 
all  the  possible  evolutions  are  obtained  by  the  repeated  composition  (synchro¬ 
nized,  or  in  sequence,  or  in  parallel)  of  certain  small  basic  tiles  called  rewrite 
rules. 

In  the  case  of  actors  and  7r-agents,  it  is  convenient  to  take  a  coordina¬ 
tion  [20]  point  of  view  and  to  distinguish  between  the  behavior  of  agents  in 
isolation  and  the  behavior  of  coordinators,  i.e.  of  system  components  whose 
role  is  to  connect  agents  and  to  control  their  behavior.  This  approach  allows 
us  to  abstract  from  the  behavior  in  the  small  of  agents,  which  is  presented  in 
a  state  transition,  syntax-independent  form,  and  to  focus  on  the  behavior  of 
coordinators,  which  are  the  most  characteristic  feature  of  distributed  systems. 
Correspondingly,  we  distinguish  between  two  kinds  of  rewrite  rules:  activity 
rules  and  coordination  rules.  An  activity  rule  describes  an  evolution  of  a  single 
sequential  agent,  and  may  produce  some  action  at  its  interface  with  the  rest 
of  the  system.  A  coordination  rule  describes  an  evolution  of  a  coordinator, 
and  may  both  require  certain  actions  from  the  agents  it  controls,  and  produce 
actions  for  a  coordinator  operating  at  a  higher  level. 

For  actors  and  7r-agents,  the  interfaces  with  the  rest  of  the  system  contain 
the  free  names  of  the  agent,  or,  equivalently,  the  acquaintances  (including 
self)  of  the  actor.  We  call  both  of  them  names.  An  important  difference  with 
the  ordinary  semantics  of  both  calculi  is  that  in  our  approach  names  have 
only  a  local  scope.  Thus  if  in  a  particular  subsystem  there  are  n  names,  we 
can  just  denote  them  with  xi,X2,  ■  •  •  ,Xn.  This  choice  makes  the  handling  of 
names  much  easier,  especially  in  the  presence  of  bound  (restricted)  names 
and  of  name  extrusion  steps:  it  avoids  a-conversion,  infinite  branching  and  in 
general  the  need  of  making  provisions  for  an  infinite  number  of  possible  names 
when  connecting  with  the  external  world. 

In  addition  to  names,  the  interfaces  contain  also  events.  Events  are  the 
mechanism  we  use  for  establishing  concurrency  control  in  a  distributed  system. 
Agents  and  messages  include  references  to  the  events  which  generated  them, 
and  to  the  previous  events  which  caused  these  events.  For  instance  in  the  event 
diagram  semantics  [12,34],  when  a  message  is  received,  a  new  event  is  created, 
and  pointers  to  it  and  its  causes  are  made  available  to  all  the  components 
spawned  by  the  step.  The  causes  of  this  new  event  are  the  events  both  the 
message  and  the  receiving  agent  pointed  to.  The  causal  relation  determines 
the  orderings  in  which  the  events  can  happen:  all  the  sequential  orderings 
compatible  with  the  causal  relation  are  possible,  and  they  correspond  to  the 

®  Even  in  an  asynchronous  system,  synchronization  is  required  to  model  the  reception  of 
messages  and  the  extrusion  of  names. 
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same  concurrent  computation. 

In  the  representation  of  agents,  actions  and  events,  the  key  notion  is  shar¬ 
ing.  In  fact,  the  only  role  of  a  name  is  to  specify  which  agents  share  it,  and 
similarly  several  events  may  share  the  same  cause.  Sharing  is  a  well-studied 
notion  from  a  formal  point  of  view,  in  particular  for  the  subterms  shared  by 
a  term.  For  instance,  terms  can  be  broken  into  the  parallel  and  sequential 
composition  of  term  constructors  and  basic  substitutions,  modulo  certain  ax¬ 
ioms.  Sharing  in  its  purest  form  is  then  represented  by  the  basic  substitution 
V  from  one  variable  to  two  values: 

V :  1  ^  2  =  {t/i  :=  Xi,y2  :=  Xi}. 

However,  in  the  algebra  of  terms  and  substitutions,  sharing  is  not  a  first  class 
component,  in  the  sense  that  it  can  be  freely  removed  by  copying  the  shared 
subterm.  In  the  representation  of  agents,  instead  of  terms  we  use  an  extended 
version  of  term  graphs.  Term  graphs  are  more  expressive  than  terms,  since 
terms  graphs  with  a  different  amount  of  sharing  among  subterms  are  actually 
different.  As  a  consequence,  in  term  graphs,  the  V  operator  becomes  a  basic 
constructor. 

2  Interoperability  of  Actors  and  Agents 

In  the  ordinary  syntax  of  actors  and  7r-agents,  we  have  three  configuration 
operators:  parallel  composition,  restriction  and  renaming.  Parallel  composi¬ 
tion  is  very  powerful,  since  references  to  the  same  name  on  both  operands  are 
automatically  identified.  In  our  approach,  since  names  are  only  local,  paral¬ 
lel  composition  considers  all  names  as  different  and  yields  the  union  of  the 
two  subsystems  without  establishing  any  connection  between  them.  Names 
are  actually  identified  by  the  A  matching  operator,  which  is  thus  our  second 
coordinator.  The  A  operator  is  analogous  but  opposite  to  V,  since  it  merges 
two  names,  or  two  events,  into  one,  rather  that  creating  two  instances  of  the 
same  variable.  It  replaces  both  variable  substitution  _[_/_]  and  parallel 
composition  _  |  ,  which  turn  out,  somewhat  surprisingly,  to  have  analogous 

meanings. 

Renaming,  which  is  of  difficult  interpretation  in  a  distributed  setting,  be¬ 
comes  useless  and  is  discarded  ^ .  Restriction  is  mantained,  essentially  with 
the  same  meaning. 

The  main  difference  between  actor  calculus  and  7r-calculus  resides,  in  our 
setting,  in  the  different  typing  of  names  and  in  the  different  versions  of  A’s 
and  their  coordination  rules.  The  free  names  of  a  7r-agent  are  all  typed  c  (for 
channel)  and  thus  there  is  only  one  A,  which  we  call  A'^.  Given  an  actor,  its 
name  is  typed  a,  while  its  acquaintances  are  typed  r  (for  reference).  Also,  all 

*  A  weak  notion  of  renaming,  permutations,  is  used.  They  correspond  exactly  to  substitu¬ 
tions  of  the  form  p  :  2  ^  2  =  {yi  :=  X2,y2  •=  a:i}.  However,  they  just  describe  a  “wire 
twisting” ,  they  have  no  coordinating  role,  and  no  rewrite  rule  matches  a  substitution. 
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Coordinator 
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A’’ 
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j^re 

Type 

ar  a 

rr  r 

cc  c 
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re  — >  € 

Permeability  to  : 

output 
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y 

y 

n 

n 

input 

y 

— 

y 

n 

n 

synchronization 

y 

— 

y 

y 

y 

Table  1 

Permeability 

of  coordinators  for 

name  sharing. 

the  acquaintances  of  a  message,  including  its  addressee,  are  typed  r.  There 
are  only  two  A’s:  A*"  accepting  two  references  and  yielding  a  reference,  and 
A“  accepting  an  actor  and  a  reference  and  yielding  an  actor.  There  is  no  A 
accepting  two  actors:  this  restriction  fully  enforces  the  uniqueness  of  actor 
names. 

The  behaviour  of  a  A  is  determined  by  its  permeability  to  input/output 
actions  and  to  synchronization.  It  is  easy  to  see  that  A*^  must  be  permeable 
to  everything,  while  A’’  cannot  be  presented  with  any  input  action,  and  thus 
cannot  synchronize  either.  The  most  interesting  case  is  A“,  which  is  permeable 
to  input  and  synchronization,  but  impermeable  to  output.  The  rationale  under 
this  restriction  is  that  a  message  cannot  exit  a  system  if  its  addressee  is  inside 
the  system.  The  permeability  of  the  various  A  coordinators  is  summarized  in 
Table  1. 

Actors  and  7r-agents  are  connected  by  coordinators  that  match  channels 
and  actor  names  or  references  and,  at  the  same  time,  restrict  visibility  of  the 
matched  pair.  Coordinator  accepts  a  channel  and  an  actor  name  and  yields 
nothing:  it  allows  a  message  to  be  sent  from  a  7r-agent  to  the  named  actor,  by 
sending  the  message  on  the  matching  channel.  Symmetrically,  accepts  an 
actor  reference  and  a  channel  and  yields  nothing:  it  allows  a  message  to  be 
sent  from  an  actor  to  a  vr-agent  receiving  on  the  named  channel,  by  sending 
the  message  to  the  matching  actor  reference.  The  hiding  aspect  of  the  actor-7r 
coordinators  enforces  a  clean  separation  between  the  two  worlds,  preserving 
the  local  behavior  of  individual  agents  and  making  the  interaction  invisible 
to  the  outside  world.  To  enforce  this  separation,  names  communicated  in 
messages  are  required  to  be  newly  created  and  the  coordination  rule  matches 
and  hides  them  appropriately.  The  permeability  of  the  actor-7r  coordinators 
is  also  summarized  in  Table  1. 

Both  calculi  are  equipped  with  mobility,  thus  the  amount  of  name  sharing 
established  at  configuration  time  can  be  modified,  actually  only  increased,  at 
run  time.  In  our  setting,  new  A’s  are  created  only  by  input  instantiation,  by  a 
synchronization  where  the  output  action  is  extruding  (similar  to  a  Close  step 
for  TT-calculus)  ,  or  by  an  activity  tile  describing  the  forking  of  some  actor  or 
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some  TT-agent.  In  these  cases  only  homogeneous  subsystems,  either  both  actors 
or  both  TT-agents,  are  connected.  Synchronization  via  an  actor-7r  coordination 
rule  creates  a  new  coordinator  to  match  (and  hide)  the  actor  and  vr  versions 
of  the  communicated  name. 

For  full  composability  we  have  required  that  agent  behavior  can  not  test 
for  equality  of  names  (no  matching  construct  in  process  algebra  terms).  This 
restriction  is  also  made  for  the  actor  language  studied  in  [4].  The  restriction 
was  removed  in  the  langauge  studied  in  [24]  in  order  to  implement  synchronous 
message  passing  (remote  procedure  call)  in  terms  of  asynchronous  communi¬ 
cation.  An  alternative  might  be  to  allow  actors  to  receive  on  more  than  one 
port. 

We  conjecture  that  the  partial  order  on  events  that  is  the  observation  of 
a  tile-based  computation  for  actors  gives  the  same  semantics  to  actor  com¬ 
ponents  as  the  interaction  diagram  semantics  of  [34]  for  the  case  of  actor 
behaviors  without  matching.  The  event-based  semantics  for  the  7r-calculus 
is  new,  and  seems  like  a  natural  framework  both  for  comparing  calculi  for 
concurrent/distributed  computation  and  for  semantic  interoperation  of  het¬ 
erogeneous  systems. 

While  a  presentation  of  the  actual  rewrite  rules  for  actors,  TT-agents  and 
their  interaction  would  need  a  more  technical  presentation  of  the  tile  model 
and  of  the  data  structures  we  use,  we  hope  that  the  above  discussion  gives 
some  hints  about  our  approach,  its  motivations  and  its  advantages. 

3  Related  Work 

The  actor  model  [21,6,1,2]  is  one  of  the  first  and  best  known  models  for  con¬ 
current  distributed  systems  and  consists  of  independent  computational  agents 
which  interact  solely  via  asynchronous  message  passing.  Semantic  foundations 
for  actor  computation  have  been  given  in  [4,32-34].  An  approach  to  specifying 
and  implementing  mechanisms  for  coordination  of  actors  based  on  reflection 
is  described  in  [3]. 

The  TT-calculus  [29]  is  one  of  the  best  studied  examples  of  mobile  process 
calculi,  namely  calculi  in  which  the  communication  topology  among  processes 
can  dynamically  evolve  when  computation  progresses.  The  asynchronous  ver¬ 
sion  of  the  TT-calculus  has  been  introduced  in  [8,22]  and  studied  in  [5]. 

The  tile  model,  introduced  in  [17],  is  described  in  general  terms  in  [18,19]. 
Tiles  are  much  like  SOS  inference  rules  [31],  but  they  can  be  composed  hor¬ 
izontally,  vertically  and  in  parallel  to  build  larger  proof  steps.  Tile  systems 
generalize  Kim  Larsen  and  Liu  Xinxin  context  systems  [23]  since  they  allow  for 
more  general  rule  formats.  The  tile  model  also  extends  rewriting  logic  [25-27] 
(in  the  nonconditional  case),  since  it  takes  into  account  rewritings  with  side 
effects  and  rewriting  synchronization.  Tile  systems  can  be  seen  as  double  cat¬ 
egories  [14]  and  tiles  themselves  as  double  cells.  They  can  be  equipped  with 
observational  equivalences  and  congruences. 
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The  combined  used  of  tiles  and  term  graphs  [7,13]  for  modeling  asyn¬ 
chronous  TT-calculus  and  CCS  with  locations  [9]  has  been  described  in  [15,16]. 
Also  coordination  models  equipped  with  flexible  synchronization  primitives  are 
presented  in  [30,11].  It  is  also  possible  [28,10]  to  translate  the  tile  model  into 
rewriting  logic,  in  order  to  take  advantage  of  important  features  of  rewriting 
logic,  like  execution  strategies  and  reflective  logics,  and  to  employ  its  existing 
implementations. 
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1  Introduction 

We  propose  here  a  new  form  of  graphical  notation  for  specifying  open  dis¬ 
tributed  object  systems.  The  primary  design  goal  is  to  make  a  form  of  nota¬ 
tion  for  defining  message-passing  behavior  that  is  expressive,  intuitively  un¬ 
derstandable,  and  that  has  a  formal  underlying  semantics. 

Specification  diagrams  are  graphical  structures.  Many  specification  lan¬ 
guages  that  have  achieved  widespread  usage  have  a  graphical  foundation:  en¬ 
gineers  can  understand  and  communicate  more  effectively  by  graphical  means. 
Popular  graphical  specification  languages  include  Universal  Modelling  Lan¬ 
guage  (UML)  and  its  predecessors  [RJB98],  and  StateCharts  [Har87].  UML 
is  the  now-standard  set  of  object-oriented  design  notations;  it  includes  several 
different  forms  of  graphical  specification  notation.  Our  aim  here  is  a  language 
with  similar  intuitive  advantage  but  significantly  greater  expressivity  and  for¬ 
mal  underpinnings.  The  language  is  also  designed  to  be  useful  throughout 
the  development  lifecycle,  from  an  initial  sketch  of  the  overall  architecture  to 
detailed  specifications  of  final  components  that  may  serve  as  documentation  of 
critical  aspects  of  their  behavior.  Its  design  was  inspired  by  concepts  from  ac¬ 
tor  event  diagrams  [Cli81],  process  algebra  [Mil80,Hoa85],  and  UML  Sequence 
Diagrams  [RJB98].  In  this  particular  presentation  the  underlying  communi¬ 
cation  assumptions  we  use  are  those  taken  from  the  actor  model:  object-  and 
not  channel-based  naming,  and  asynchronous  fair  message  passing. 

1.1  Actor  Concepts 

We  provide  here  a  very  brief  overview  of  actor  concepts;  see  [Agh86,  AMST97,Tal97] 
for  more  complete  descriptions. 

Actors  are  distributed,  object-based  message  passing  entities.  Since  actors 
are  object-based,  they  each  have  a  unique  name,  and  actors  may  dynami¬ 
cally  create  other  actors.  Individual  actors  independently  compute  in  par- 

^  This  work  was  partially  supported  by  NSF  grant  CCR-9312433 
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allel,  and  actors  only  communicate  by  message  passing.  Messages  are  sent 
asynchronously,  so  the  sender  may  continue  computing  immediately  after  a 
message  send.  Messages  are  of  the  form  a  <  M,  indicating  message  M  is  sent 
to  actor  a.  Officially,  we  have 

Definition  1.1  (A,  M,  MP)  Define  a  G  A  to  be  a  fixed  countably  infinite  set 
of  actor  names;  M  to  be  a  set  of  message  expressions;  and, 

mp  E  MP  =  A<M  U  A<M:k 

to  be  the  set  of  message  packets  for  k  E  Key  a  countable  set  of  keys  (e.g. 
Key  =  NatJ.  We  will  write  A  <  M{  :  k}  for  a  message  packet  that  may  or 
may  not  have  a  key.  The  keys  serve  a  technical  purpose  which  is  described 
below. 

All  messages  must  eventually  arrive  at  their  destination,  but  with  arbi¬ 
trary  delay.  At  this  point  they  may  be  queued  if  the  destination  actor  is 
busy.  Additionally,  individual  actor  computations  must  never  starve.  These 
two  guarantees  of  progress  are  the  fairness  assumptions  of  actor  computation. 
There  is  no  programming  language  for  actors;  one  possible  language  is  defined 
in  [MT97]  but  others  are  possible.  A  fixed  semantic  framework  for  actors  has 
been  developed  [AMST97,Tal97].  We  will  use  this  framework  as  the  basis  for 
the  developments  here. 

Actor  systems  are  intended  to  model  open  distributed  computation.  This 
means  that  the  whole  system  will  not  be  present,  and  the  framework  must 
assume  some  external  actors  are  interacting  with  the  local  system.  Addition¬ 
ally,  of  the  local  actors,  only  some  of  their  names  may  be  known  by  external 
entities;  these  are  the  receptionists.  The  external  actors  are  notated  as  the  set 
X,  and  the  receptionists  the  set  p.  These  sets  may  grow  over  time:  the  external 
actors  will  grow  based  on  names  received  in  messages  from  the  outside,  and 
receptionists  may  grow  if  new  local  names  are  sent  out  in  messages. 

Actor  systems  may  be  modeled  by  the  set  of  possible  sequences  of  inputs 
and  outputs  they  may  perform  over  time.  We  call  one  such  sequence,  possibly 
infinite,  an  interaction  path,  and  model  actor  system  behavior  by  a  set  of  such 
paths.  The  technical  details  of  this  model  are  summarized  in  section  3. 

2  Specification  Diagram  Notation 

We  begin  with  the  graphical  notation  and  an  informal  idea  of  its  meaning.  Fig¬ 
ure  1  presents  the  basic  diagram  components.  Vertical  lines  indicate  progress 
in  time  going  down,  expressing  abstract  causal  ordering  on  events,  with  events 
above  necessarily  leading  to  events  below.  This  causal  ordering  will  be  termed 
a  causal  thread.  Note  there  is  no  necessary  connection  between  these  “threads” 
and  actors  or  processes,  they  exist  only  at  the  semantic  level:  a  single  thread 
of  causality  may  be  multiple  actors,  and  a  single  actor  may  have  multiple 
threads  of  causality.  The  components  listed  in  Figure  1  are  composed  to  form 
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new  X  fresh  x  phi 


X  :=  psi 


X 


D 


New  Fresh  Constrain  Assign  Recursion  Rec.  var  Scope 
Fig.  1.  Specification  Diagram  Components 

specification  diagrams.  Each  form  of  diagram  component  has  a  single  in-edge 
and  out-edge — the  figure  serves  as  a  grammar  for  the  diagrams. 

sequencing  Vertical  lines  (causal  threads)  represent  necessary  temporal  se¬ 
quencing  of  events. 

parallel  Events  in  the  parallel  diagrams  have  no  causal  ordering  between 
them,  but  are  after  events  above  and  before  events  below. 
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choice  One  of  the  possible  choices  is  taken. 

fork  A  diagram  is  forked  off  which  hereafter  will  have  no  direct  causal  con¬ 
nection  to  the  current  thread  (however,  messages  could  indirectly  impose 
some  causality  between  the  two). 

skip  Nothing. 

send  A  message  is  sent. 

receive  A  message  is  received  by  actor  a,  possibly  binding  pattern  variables 
in  the  message  M,  which  can  be  used  below  in  the  diagram. 

send-receive  A  message  is  sent  from  one  component  of  the  diagram  to  an¬ 
other,  producing  a  causal  cross-connection  in  what  could  have  been  causally 
unrelated  segments. 

loop  The  diagram  is  iterated  some  number  n  times,  where  n  is  nondetermin- 
istically  chosen  from  the  interval  0 . . .  oo.  The  case  n  =  oo  means  it  loops 
forever. 

EOD  Denotes  the  end  of  a  causal  thred  in  the  diagram, 
scope  Brackets  demarcate  static  scoping  of  diagram  variables, 
recursion  A  boxed  diagram  fragment,  may  refer  to  itself  by  name,  X. 
new  A  fresh  diagram  variable  x  is  allocated,  with  arbitrary  contents. 

fresh  A  fresh  diagram  variable  x  is  allocated,  with  contents  an  actor  name 
not  currently  in  use. 

constraint  An  arbitrary  constraint  is  placed  on  the  current  thread  of  causal¬ 
ity,  which  must  be  met.  There  is  no  direct  analogue  to  this  notion  of  con¬ 
straint  in  programming  languages:  the  constraint  may  be  any  mathematical 
expression.  And,  a  constraint  failing  does  not  indicate  an  error,  it  indicates 
that  such  a  computation  path  will  not  arise.  So,  it  is  significantly  different 
from  Hoare-style  program  assertions. 

assign  A  variable  is  dynamically  assigned  a  new  value.  The  assignment  body, 
if),  can  be  any  sensible  mathematical  expression. 

Specification  diagrams  are  truly  a  specification  language — ^for  internal  mes¬ 
sages,  both  source  and  target  are  shown,  meaning  there  is  a  nonlocal  constraint 
on  both  sender  and  receiver  of  message  delivery.  On  this  point  they  differ  from 
existing  forms  of  concurrent  language. 

There  is  no  requirement  that  the  choice  be  fair,  in  the  sense  that  for  a 
particular  actor  computation  the  same  branch  could  always  be  taken.  How¬ 
ever,  there  is  a  requirement  that  message  delivery  be  fair,  in  the  sense  that 
any  message  sent  must  eventually  arrive  at  its  destination. 

The  parallel  and  fork  operators  are  similar,  but  parallel  threads  must  even¬ 
tually  merge,  while  forked  threads  are  asymmetrical  in  that  the  forked  threads 
need  never  merge. 
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A  top-level  specification  diagram  includes  an  interface,  notated  D^.  Top- 
level  diagrams  are  modules  which  may  be  directly  given  semantic  meaning. 
We  will  not  always  include  the  phrase  “top  level”  but  meaning  should  be  clear 
from  context. 

In  this  brief  paper  we  will  use  a  textual  notation  and  not  the  diagrammatic 
notation. 


2.1  Textual  Notation  for  Diagrams 


We  give  an  equivalent  textual  form  for  diagrams.  This  will  also  be  considered 
the  “official”  syntax,  and  full  details  will  be  given.  Diagrams  may  be  easily 
mapped  into  the  textual  syntax. 

The  set  of  variables  Xd  is  the  set  of  diagram  variables  x,y,  z,  ...  used  in 
diagrams.  These  variables  may  take  on  values  in  some  mathematical  universe 
U  which  we  keep  open-ended;  it  could  be  instantiated  with  a  set  theory  or 
type  theory.  We  assume  the  basic  collections  of  the  actor  theory  are  contained 
in  U:  A,  M,  MP,  true,  false  C  U.  To  avoid  circular  mathematical  definitions, 
we  assume  U  is  fixed  before  meaning  of  specification  diagrams  is  assigned. 
And,  we  assume  acq{s)  for  s  G  U  is  defined  and  constrain  it  to  be  a  finite 
subset  of  A. 

The  notion  of  message  packet  MP  defined  earlier  included  an  optional  key. 
Keys  are  necessary  to  give  a  textual  representation  to  the  send-receive  edges 
in  diagrams,  constraining  a  send  to  be  connected  to  its  corresponding  receive 
by  sharing  the  same  key.  The  interaction  paths  will  not  contain  keys,  they  are 
used  for  local  synchronization  only. 

Specification  diagram  message  packets  MPa  are  packets  of  MP  parame¬ 
terized  by  diagram  variables  Xa- 

Definition  2.1  (MPa,  Ma,  Aa)  Let  MPa  be  Aa  <  Ma  U  Aa  <  Ma  :  k  where 
Aa  =  (Xa  U)  — >•  A  and  Ma  =  (Xa  — ^  U)  — >■  M. 

The  parameter  e  G  Xa  — >•  U  is  an  environment  interpreting  free  diagram 
variables.  We  use  the  informal  convention  that  message  expression  Ma  =  x-\-l 
is  an  abbreviation  for  Ma(£)  =  e{x)  -I- 1. 

Specification  diagrams  may  now  be  defined  officially  by  the  following  gram¬ 
mar. 

Definition  2.2  (Specification  Diagram  Grammar)  The  specification  di- 
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agrams,  D  G  D,  are  defined  by  the  following  grammar. 


name 

textual  notation 

skip 

skip 

sequence 

Di,D2 

parallel 

Di  li  D, 

choice 

D\  0  D2 

scope 

{D} 

fork 

fork(Z?) 

receive 

receive  (mpa) 

send 

send(mpd) 

constraint 

constrain((^) 

new  variable 

new(a;) 

fresh  actor  name 

fresh  (x) 

assignment 

•• 

It 

recursion 

recX.D 

recursion  variable 

X 

where  Dj  G  ID  are  diagrams,  and  X  G  is  a  countable  set  of  recursion 
variables.  A  top  level  diagram  is  a  diagram  uhth  an  interface,  D^. 

Sequencing  is  right-associative,  and  binds  most  tightly,  followed  by  choice  and 
then  parallel  composition  binding  most  loosely.  We  use  an  implicit  static 
variable  binding  convention:  new(rc),fresh(a;),  and  receive(ad  <  Md{  :  «}), 
with  X  informally  occurring  in  M^,  all  denote  implicit  bindings  (declarations) 
of  variable  x.  { . .  • }  denotes  a  scope  boundary,  giving  the  static  end  of  any 
implicit  declarations  contained  immediately  within.  The  extent  of  a  variable 
binding  is,  intuitively,  all  points  which  causally  must  follow  the  binding,  and 
that  are  at  the  same  or  deeper  scope  boundary.  Thus  for  instance  in  (new(x)  || 
skip);x  :=  5,  the  assignment  to  x  is  within  the  scope  of  the  new  since  this 
assignment  causally  must  follow  the  declaration  of  x.  If  ||  were  replaced  by 
0  in  this  example,  the  assignment  x  would  not  be  bound  (in  fact  it  would  be 
partially  bound:  if  the  left  choice  were  taken  it  would  be  bound,  but  not  if 
the  right  choice  were  taken). 

The  assignment  expression  is  informally  a  function  on  U  which  may 
refer  to  variables  in  Xj;  formally,  if  G  Pa;[A]  x  Pa,[A]  x  (Xa  — >■  U)  ^ 
U:  it  takes  as  parameter  a  tuple  {p,x,£)  where  the  environment  s  gives 
mathematical  meaning  to  the  free  variables,  and  if  may  refer  to  actors  in 
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p  and  X-  Predicates  on  U  are  notated  (j),  and  are  formally  predicates  on 
P,[A]  X  P,[A]  X  (Xd  — >  U).  Informally,  we  will  write  e.g.  “a;  €  p”  to  mean 
a  predicate  (j)  where  (f>{p,x,£)  iff  €  p.  acq{D)  is  defined  as  {acq{s)  \  s  € 

U  occurs  as  an  mp^,  0  or  '0  in  D}. 

We  use  the  convention  that  ExampleMacro(a;,  y,  2)  =  D  defines  a  macro. 
Macros  are  just  functions:  we  will  be  careful  not  to  define  self-referential 
macros.  Certain  syntax  is  easily  encodable  via  macros  and  so  is  not  defined 
in  the  core  grammar. 

Definition  2.3  (Diagram  Macro  Library)  nondeterministic  iteration: 
W1  °  =  rec  X.  ( (D;  X)  ©  skip) 

interval  iteration:  [£)]* "  •^  = 

new(a;);  constrain(i  <x<  j); 

recX.constrain(a;  =  0)  ©  constrain(a;  >  0);  a:  :=  x  —  1;  D\  X 

for  fresh  variable  x 
if-then:  if  (p  then  Di  else  D2  = 

(constrain(^);Di)  ©  (constrain(-i0);  D2) 

while- do:  while  <j)  do  D  = 

recX.(constrain(^);  D;  X)  ©  constrain (-i(^) 

end  of  diagram:  eod  =  recX.(skip;X) 
abort  path:  abort  =  constrain(/olse) 
initialized  new:  new(x  =  s)  =  new(x);  constrain(x  =  s) 
constrained  new:  new(x  G  -S')  =  new(x);  constrain(x  G  -S) 
constrained  receipt:  receive(ad  <3  G  -S)  = 

receive(ad  <  Mi);  constrain(Md  G  S) 

Translation  from  informal  diagrams  into  textual  notation  is  straightforward 
from  the  above  in  all  cases  except  the  internal  message  edges.  With  these 
internal  edges,  a  diagram  can  take  on  an  arbitrary  graph  structure,  and  this 
cannot  be  placed  in  purely  textual  notation.  The  purpose  of  keyed  message 
packets  is  precisely  to  capture  the  1-1  relation  implied  by  an  internal  edge:  the 
sender  and  receiver  must  be  paired  with  no  other  send/receive  to  this  message. 
Thus,  for  each  internal  edge  in  a  diagram,  a  fresh  key  k  is  assigned  to  it,  and 
message  ad<Md  on  the  message  edge  translated  into  a  send(od<Mi  :  «)  action 
by  the  sender  and  a  receive (od  <  Md  :  k)  action  by  the  receiver. 
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2.2  Small  Examples 

We  now  give  a  series  of  small  examples  to  illustrate  use  of  the  language.  None 
of  the  examples  attempts  to  seriously  illustrate  the  usefulness  of  the  language 
for  specifications,  as  the  examples  are  too  small;  the  goal  here  is  just  to  give 
informal  clarification  of  the  syntax  and  semantics. 


Message  Passing  Semantics 

Message  passing  in  diagrams  differs  from  actor  programming.  Diagram 
messages  are  specifications  that  a  message  was  sent  on  one  end  and  actively 
processed  on  the  other.  For  instance,  consider  a  sink: 

Sink(a)  =  [receive(a 

A  sink  behavior  in  an  actor  is  a  behavior  that  does  nothing;  messages  will 
automatically  queue  up.  At  the  specification  level,  we  need  to  specify  the 
receipt  of  those  messages  that  are  forever  ignored.  The  diagrams  do  implicitly 
account  for  the  asynchronous  nature  of  actor  communication:  a  message  edge 
only  constrains  the  send  to  be  before  the  receive,  not  for  the  two  to  happen 
simultaneously.  The  use  of  “0 . . .  oo”  iteration  models  all  possible  environment 
behaviors.  The  environment  may  send  0,  an  arbitrary  number,  or  infinitely 
many  messages. 

The  interaction  path  semantics  of  the  tof)-level  diagram  Sink(o)0“^  have 
paths  of  the  following  form.  Each  path  consists  of  a  sequence  of  input  messages 
a<M.  Since  the  system  is  reactive,  the  environment  could  send  0, 1, 2, . . .  ,  n, . . . 
or  even  infinitely  many  such  messages.  No  messages  are  sent  out. 

So,  a  point  about  message  passing  in  diagrams  is  that  messages  which  will 
never  be  processed  must  be  specified  as  arriving.  Consider 

[receive(a <x);  constrain(a;  >  100)  ...]°"°° 

This  specification  may  at  first  look  analogous  to  a  synchronization  constraint 
that  only  processes  messages  with  contents  larger  than  100.  However,  a  syn¬ 
chronization  constraint  of  this  form  will  implicitly  forever  ignore  messages  with 
contents  less  than  100.  The  above  specification  instead  constrains  the  environ¬ 
ment:  it  requires  that  such  messages  will  in  fact  never  be  sent.  Specifications 
which  constrain  the  environment  are  partial. 


Ticker 

A  ticker  is  a  simple  actor  which  increments  a  counter  upon  receipt  of  a 
tick  message,  and  replies  to  time  messages  with  the  current  time.  First,  a 
partial  specification  of  a  ticker  is  given  which  only  specifies  that  time  replies 
are  numerical,  not  that  the  number  of  tick  inputs  is  counted.  This  shows  how 
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specifications  may  underconstrain  the  program  space. 

PartialTicker(o) = 

[receive  (a  <tick)]°"  °°  || 

[receive(a<itiine@a:);  new(y  €  Nat);  send(r  <  reply(y))]®"°° 

The  possible  interaction  paths  for  the  top-level  diagram  PartialTicker^a}0 
may  be  informally  described  as  any  path  satisfying  the  following.  For  each 
o<3time@c  input  in  the  path,  there  is  later  a  c<reply(n)  output  for  arbitrary 
n  €  Nat,  and  all  outputs  are  reply  messages  so  paired.  There  also  may  be 
any  number,  including  infinitely  many,  a  <  tick  input  messages  in  any  order. 

Next  we  give  a  high-level  specification  of  the  full  ticker:  it  gives  a  sequence 
of  replies  to  time  messages  in  a  non-decreasing  sequence. 


Ticker(c)  = 

[receive(a  <3 tick)]® || 
new(count  6  Nat); 

[receive(a  <  time@a;);  new(?/ €  Nat); 

count  :  =  coimt  -H  y;  send(x  <  reply(coxmt))]®"  °° 

The  actual  implementation  of  a  ticker  we  are  specifying  sends  tick  mes¬ 
sages  to  itself  to  increment  the  counter:  every  time  it  receives  a  tick,  it  in¬ 
crements  the  counter  and  sends  itself  another  tick.  A  low-level  specification 
which  is  more  close  to  an  actual  implementation  is 

IntensionalTicker(o) = 

send(a  < tick);  new(count  =  0); 

[(receive(o  <  tick); 

count  :=  count  -1- 1;  send(fl  <  tick)) 

©  (receive(a  <  time@a;);  send(a:  <  reply(coTmt)))]®"°° 

Note  that  tick  messages  could  in  theory  be  sent  by  the  environment.  We 
then  desire  to  establish  equivalences  on  top-level  diagrams  such  as 

Ticker(o)0“^  =  IntensionalTicker(a)0“^ 

to  show  a  high-level  specification  is  equivalent  to  a  low-level  one.  Extensional 
equivalence  =  is  defined  in  Section  5. 
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The  above  diagrams  have  a  restricted  acceptable  message  input  set:  mes¬ 
sages  must  be  in  {tick,  time},  and  so  the  diagrams  are  partial.  It  is  not 
difficult  to  extend  a  diagram  to  a  diagram  without  acceptable  message  re¬ 
strictions: 

CompleteTicker(a) = 

fork([receive(o<a:);  constrain (mspMet/i (a:)  ^  {tick,  time})] 
Ticker(a) 


Ticker  Factory 

This  example  shows  how  a  fresh  actor  may  be  dynamically  generated. 

TickerFactory(a)  = 

[receive(a  <new@c); 
fresh(a;); 
fork(Ticker(a:)); 
send(c  <  reply(a:))]°"°° 


Function  Composer 

We  assume  as  given  two  mathematical  functions  F  and  G  which  are  defined 
over  all  possible  messages.  First  we  specify  an  abstract  function-computer 
behavior. 

Fimction(a,  /)  = 

[fork(receive(a  <  compute (a;)@c);  send(c<reply(/(x)))]°”  °° 

If  the  fork  above  was  not  present,  the  specification  would  implicitly  order  the 
function  calls.  However,  since  the  function  call  order  is  irrelevant,  the  forkless 
specification  would  show  causal  ordering  that  was  not  necessary.  The  forking 
and  forkless  versions  are  in  fact  equivalent,  however,  in  the  sense  that  they 
specify  the  same  set  of  interaction  paths. 

An  actor  which  computes  G  o  F  is  then  specified  as  Function(a,  G  o  F). 
A  hypothetical  implementation  may  use  two  distinct  actors  Function(aF,  F) 
and  Function(oG,  G)  to  compute  F  and  G  respectively,  and  a  Composer  actor 
used  to  put  together  the  composition.  The  system  with  these  three  actors 
should  meet  the  above  specification.  The  Composer  is  specified  as  follows. 
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Composer(a,  /,  g,  Uf,  Ug)  = 

[receive(a  <  compute  (a;)  @c); 

fresh(a;/);  send(a/ <i  compute(x)@a:/);  receive(ar/ <reply(a:)); 
fresh(xj,);  send(ap  <  compute(a:)@a;j);  receive(a;<,  <  reply(a;)); 
send(c  <i  reply(a;))]°"°° 

The  complete  low-level  specification  is  then  the  parallel  composition  of 
these  three: 

FunctionComposer(fl,  F,  G,  ap,  ag)  = 

Composer(a,  F,  (j,  Ojr,  og)  ||  Function(ai?,  F)  ||  Function(aG,G) 

In  an  open  distrubuted  system,  components  may  be  designed  as  separate  top- 
level  diagrams  and  then  composed.  In  particular  for  large  systems  for  which 
the  design  is  distributed  across  different  political  entities,  object-based  com¬ 
ponents  are  composed.  For  this  example,  the  top-level  composition  is  defined 
as  follows. 

FunctionComposerModule  (a,  F,  G,  ap,  00)0"^  = 

Composer(a,  F,  G,  oj?,  aGf){“],_ao}  H  Function(aj7’,  ||  Function(aG,G)0“®^ 

where  ||  is  not  the  composition  operator  on  diagrams,  but  the  composition 
operator  on  top-level  specifications.  Theorem  5.3  below  may  be  used  to  show 
the  two  methods  for  composition  produce  the  same  specification: 

FimctionComposer(a,  F,  G,  ap,  00)0**^  —  FunctionComposerModule  (c,  G  o  F)^**^ 

This  specification  is  equivalent  to  the  abstract  Function(a,  G  o  F): 


FunctionComposer(o,  F,  G,  ap,  00)0**^  —  Function(a,  G  o  F)^**^ 

We  sketch  how  an  argument  to  establish  this  equivalence  would  proceed. 
The  first  step  is  to  perform  a  “zipping”  transformation  on  FunctionComposer 
to  connect  send  and  receive  to  give  send-receive  cross-edges.  This  is  a  point 
where  the  diagrammatic  semantics  becomes  significantly  more  readable  than 
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the  textual  form. 

ZippedFuiictionComposer(a,  /,  g,  af,  Og)  = 

[receive(a  <  compute(a;)@c);  fresh(a;/);  fresh(a;g); 
send(a/ <1  compute(a;)@a;/  :  k/);  receive (x/ <reply(/ (a;))  :  k^); 
send(aj  <  compute  (re)  :  Kg);  receive(a;p  <reply(5'(a:))  :  Kg); 

send(c<  reply(a;))]®  "  °°  || 

[fork(receive(a/ <1  compute(a:)@a:/  :  Kf);  send(x/ <reply(/(a;)  :  /c^))]°"°°  || 
[fork(receive(aj  <1  compute(a;)@a;p  :  Kg);  send{xg  <  reply {g{x)  : 

The  ZippedFunctionComposer  is  an  intermediate  stage  in  the  incremental 
translation  of  FunctionComposer  to  Function.  By  proving 

FunctionComposer(a,  F,  G,  ap,  o.g)Y^  — 

ZippedFunctionComposer  (a,  F,  G,  ap,  00)0°^  — 

Function(a,  G  o 

the  desired  equivalence  is  established. 

Simple  Memory  Cell 
Cell (a) = 

new(ar);  (*  cell  value,  initially  arbitraury  *) 

[  (receive(o<  set(u)@c);  (*  c/v  are  pattern  variables  *) 

X  :=v; 

send(c<ack)) 

0 

(receive(a  <  get@c); 
send(c<reply(a:))  ]°“°° 

A  top-level  specification  for  a  memory  cell  is  then  Cell (0)0“^.  Another 
powerful  idea  is  to  write  a  partial  specification  which  only  responds  to  message 
input  patterns  that  are  semantically  sensible.  For  instance,  for  a  cell,  receipt 
of  a  get  before  any  set  messages  have  arrived  is  unreasonable;  we  thus  make 
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a  specification  which  constrains  the  environment  to  never  do  this. 

EnvironmentConstrainingCell  (a)  = 

new(a;  =  rmdef ined);  (*  cell  initially  undefined  *) 

[  (receive (a  <  set(u)@c); 

X  :=  v\ 

send(c  <  ack)) 

© 

(receive(a  <  get@c);  constrain(a;  ^  undefined) 
send(c  <  reply(r))  ]°'  °° 

Environment  constraints  are  a  powerful  aspect  of  specification  diagrams.  Such 
specifications  are  partial:  they  are  not  defined  for  all  patterns  of  input.  Com¬ 
position  with  such  specifications  is  also  partial,  as  it  may  fail  since  the  spec¬ 
ification  is  not  fully  reactive.  However,  the  concept  of  satisfaction  of  an 
environment-constrained  specification  is  a  difficult  one  and  so  now  we  will 
generally  study  complete  specifications  only. 

3  A  Path-Based  Framework  for  Actors 

In  this  section  we  briefly  review  the  semantic  framework  used  to  model  ac¬ 
tor  systems;  this  framework  will  then  be  used  to  model  specification  diagrams. 
See  [Tal97]  for  details;  here  we  provide  a  terse  and  simplified  presentation.  We 
use  a  path-based  (trace-based)  semantics:  an  open,  nondeterministic  system 
is  interpreted  as  a  set  of  interaction  paths.  Each  path  is  a  possibly  infinite  list 
of  input  and  output  actions.  Interaction  path  semantics  models  an  actor  sys¬ 
tem  in  terms  of  the  possible  interactions  (patterns  of  message  passing)  it  can 
have  with  its  environment.  Interaction  semantics  does  not  let  us  use  any  infor¬ 
mation  about  internal  computations  or  what  actors  may  be  initially  present 
or  known  beyond  those  specificed  in  the  interface.  A  specification  diagram 
is  given  meaning  as  a  set  of  interaction  paths,  so  the  meaning  of  a  diagram 
D  may  be  the  same  as  the  meaning  of  some  actor  program  implementation. 
If  this  is  in  fact  the  case,  we  can  assert  that  the  implementation  meets  the 
specification  D. 


Interfaces 

An  actor  system  interface  is  a  pair  ^  of  disjoint  finite  sets  of  actor  names. 
p  specifies  the  receptionists  and  x  specifies  the  external  actors  known  to  the 
system. 
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We  define  parallel  composition  of  interfaces  by 
«Mg  iff  pinp2  =  0 

S  II  g  =  SX)-(«u«).  provided  «  Mg 


Events 

In  order  to  distinguish  differrent  occurrences  of  message  packets  with  the 
same  contents  we  use  a  set,  E,  of  events.  Each  event,  e,  contains  a  message 
packet,  pkt{e)  e  MP.  We  let  e  range  over  E  and  E  range  over  PfE].  We 
write  in(e)  to  distinguish  the  arrival  of  a  message  from  outside  the  system 
from  its  delivery  e.  We  also  write  out(e)  to  distinguish  delivery  of  a  message 
to  the  environment  from  from  the  actual  delivery  to  the  target  actor.  We  let 
E  be  the  set  of  events  extended  by  these  input/output  events 

E  =  E  U  in(E)  U  out(E) 

and  we  let  e  range  over  E  and  E  range  over  PfE].  We  will  use  a  simple  theory 
of  potentially  infinite  lists,  notated  [xi,  X2, . . .  ,  . . .  ].  List  concatenation  is 

written  and  for  the  case  where  the  first  list  is  infinite  returns  that 

as  the  result.  Unit  for  concatenation  is  the  empty  list,  [  ].  5”  List  is  the  set  of 
lists  with  elements  from  S. 


Interaction  Paths 

An  interaction  path  is  a  possibly  infinite  list  of  input/output  events. 


TT  =  [ei,  62,...  ,  ejfc, . . .]  e  (in(E)  U  out(E))  List. 


It  represents  a  potentially  infinite  sequence  of  interactions  of  a  system  with 
its  environment  as  observed  by  some  hypothetical  observer,  represents 
an  interfaced  interaction  path,  a  path  with  the  indicated  interface.  All  of 
the  interaction  paths  constructed  in  this  paper  are  constrained  to  obey  the 
EPLaw  of  [Tal97].  EPLawiir)  requires  inputs  of  tt  to  be  to  receptionists  or 
names  sent  in  a  previous  output,  and  outputs  to  be  to  external  actors  or 
actors  whose  name  was  received  in  a  previous  input.  EPLaw  corresponds  to 
the  Baker-Hewitt  locality  laws  governing  how  actors  become  acquainted  with 
one  another. 

3.1  Interaction  Path  Sets  and  their  Algebra 

An  interaction  path  models  one  possible  way  a  system  might  interact  with 
its  environment.  We  model  the  behavior  of  a  system  by  sets  of  interfaced 
interaction  paths.  Ip. 
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Parallel  Composition 

We  define  composability  and  composition  on  interaction  path  sets.  The 
basic  operation  for  composing  paths  is  dovetailing  two  interaction  paths,  ttq  Z 
TTi-  This  operation  is  defined  in  terms  of  precursor  tto  Z®  tti,  which  is  the 
greatest  symmetric  function  closed  under  the  following  (in  the  following  we 
abuse  notation  and  write  [...]*  5  to  mean  {[...]*  s  |  s  €  5}). 

(0)  [  ]  Z°  TT  =  {tt} 

(1)  [in(e)]  *  TTo  Z°  [out(e)]  *  tti  =  ttq  Z”  tti 

(2)  [eo]  *  TTo  Z°  [ei]  *  tti  = 

{[eo]  ♦  (tto  Z°  [ei]  *  tti)}  U 
{[ei]  *  ([eo]  *  TTo  Z°  TTi)} 

Then,  tto  Z  tti  is  defined  as  ttq  Z°  tti  with  the  paths  tt  €  tto  Z°  tti  that  after 
some  point  forever  starve  events  from  one  of  tto  or  tti  removed. 

Define  composability  and  parallel  composition  for  path  sets  Ipq  and  Ip^ 
with  interfaces  ^  and  as 

IPq  ixi  /pi  iff  CXI 

IPo  II  IPi  =  W  I  (3^0x0  ^  ^Poj'^ixi  ^  ^Pi) 

(tt  €  TTo  Z  TTi,  TTo  and  TTi  share  no  events  e,  and  ^PLaw;(7r))} 
where  ^  ||  Jj,  provided  tx] 


Restriction 

The  restriction  of  Ip  with  interface  ^  to  p'  is  defined  by 
Ip\fl  =  {tt^  I  TT^  G  /p  and  tt  contains  no  in(a  <3 M)  events  for  a  e  (p  —  p!)} 


Renaming 

Renaming  of  interaction  paths,  a(7r),  is  pointwise  on  each  event  in  the 
path,  and  renaming  on  path  sets  a{Ip)  is  pointwise  on  each  element  of  the  set. 

4  Operational  Semantics  of  Diagrams 

Diagrams  are  given  meaning  in  this  section  via  an  operational  semantics.  The 
goal  is  to  give  a  set  of  interaction  paths  defining  the  behavior  of  top-level 
diagrams  D^.  This  is  accomplished  by  defining  a  single-step  relation  mapping 
configurations  to  configurations,  the  transitive  closure  of  which  yields  a  set  of 
computation  paths.  In  this  sense  it  is  a  standard  presentation  of  operational 
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semantics  of  actors  [AMST97,Tal97].  The  main  difference  with  these  previ¬ 
ous  works  is  more  post-processing  is  required  to  remove  paths  that  are  not 
admissible.  A  configuration  is  of  the  form 

Where  p,  x  ^'I'e  the  current  receptionists  and  external  actor  names,  and  /i  C  E 
is  a  set  of  messages  in  transit,  either  to  be  sent  out  of  the  system  or  to  be 
received  locally.  Since  each  message  is  a  unique  event,  it  is  possible  to  have 
two  messages  with  identical  target  and  contents  in  p. 

4 . 1  Preliminaries 

Before  presenting  the  operational  semantics,  we  need  to  define  two  concepts. 
We  use  a  small-step  semantics  based  on  factoring  a  diagram  D  expression 
into  a  redex  £>rdx  and  reduction  (a.k.a.  evaluation)  context  R,  D  =  /2[i5rdx]- 
Notation  is  also  needed  for  looking  up,  modifying,  and  extending  variable 
bindings.  The  concepts  of  reduction  context  and  environment  are  in  fact  in¬ 
tertwined:  environments  are  local  to  particular  points  in  reduction  (so  e.g. 
parallel  threads  may  have  differing  environments)  and  so  are  spread  around 
the  reduction  context.  These  local  environments  are  functions  7i  G  Xa  — >  U 
which  hold  the  current  state  of  diagram  variables  Xa,  and  map  only  finitely 
many  variables  to  non-±  values,  ±  G  U  being  a  special  meta-value  indicating 
undefined.  A  small  addition  to  the  language  syntax  is  used  to  bind  variables 
inside  the  executing  diagram:  -{17  :  £>[}  indicates  a  lexical  scoping  construct 
{D}  under  which  execution  is  actively  occurring,  with  current  local  environ¬ 
ment  7- 

Reduction  contexts  R  (a.k.a.  evaluation  contexts)  are  used  to  isolate  the 
next  redex  to  be  reduced.  Their  grammar  is 

R  =  •  or  R\\  D  ov  D  \\  R  or  R]D  or  :  i2[[ 

R[D]  denotes  the  act  of  replacing  the  (unique)  •  in  R  with  diagram  D.  We 
will  need  notation  for  reduction  contexts  defined  as  above  but  without  the 
{17  :  i?}  case;  they  will  be  notated  R~. 

Notation  is  next  defined  for  manipulation  of  the  environment.  The  basic 
operations  needed  include  R@x  to  look  up  the  value  of  x  in  the  environments 
of  R,  R@x  :=s  to  modify  the  value  of  already-declared  variable  x,  and  R  © 
X  :  =  s  to  add  a  new  definition  of  x  in  the  innermost  lexical  level.  s(R)  extracts 
the  environment  from  R  in  the  form  of  a  function  from  diagram  variables  to 
values. 

Definition  4.1  (R@x,R@x  :=s,RQx  :-s,  s{R))  Letting 

R  =  fio  Hti  ; .  ■  •  ■  H, 

define 
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lookup  R@x  is  'Yi(x)  where  i  is  the  largest  number  less  than  or  equal  to  n 
with  7i(x)  ^  -L,  or  1.  if  all  Jiix)  =  -L. 

modify  R@x  :=s  is  i2o[{l7i  =  •■•Ri'lWi  •  •••■Rnl'llTn  :  •  •  •  I}]  •  •  •  fr] 

where  i  is  the  largest  number  less  than  or  equal  to  n  with  ^i{x)  ^  J-,  and 
-y^  =  at  all  points  except  7i(a^)  =  s.  If  no  such  i  exists,  R  is  unchanged. 

extend  i?  ©  x  :=s  is  i?o  [ilTi  =  •  ••Rni^'Yn  '■  -Rn+il}]  •••!}]  7n  =  7n  at  all 
points  except  7^1  (x)  =  s. 

extract  £{R)  =  f  where  f{x)  =  R@x.  Dom(£(il))  =  {x  |  (e(i2))(x)  J.}. 

acquaintances  acq{D)  is 

U  acq{Md)li[j  acq{<i>)  U  U  acq{'ip)  U  [J  acq{ai)  U  U  U  ac9(7(x)) 

MaeD  <i>eD  ipeD  ad€D  'yeDxeXi 

where  “•  £  D”  here  means  occurrence  as  a  subterm  in  D.  acq{R)  is  defined 
identically  to  acq{D)  except  with  the  last  clause  being  Ui<i<n  UxeXd  acq{'yn{x))- 

4.2  The  Semantic  Definition 

In  this  section  we  define  the  semantic  meaning  function  mapping  top- 
level  diagrams  to  sets  of  interaction  paths  that  describe  the  input-output  be¬ 
havior  of  the  diagram. 

Definition  4.2  The  single-step  computation  relation  on  diagram  configura¬ 
tions  is  defined  in  Figure  2. 

For  each  of  the  rules  except  in/out,  the  redex  is  the  Drdx  for  left-hand-side 

Definition  4.3  Given  a  top-level  diagram  define 
raw  event  paths  [^ojolraw  ^ 

{[labo,labi,...  ,lab„,...]  | 

progress  =  {ir  |  ir  and  for  all  configurations 

arising  in  tt,  if  Di  =  R[D]  for  some  R,  D,  then  there  is  a  later  configuration 
R'[D]^f^.  pi+j  with  redex  the  same  subterm  occurrence  D}. 

fair  Po^°olfair  =  {tt  I  tt  e  and  each  event  e  placed  in  p  during 

TT ’s  computation  is  eventually  removed  from  p  at  some  later  point  in  the 
computation  } 

interaction  paths  [Do^Jjp  =  {tt^  |  ttq  €  I-C^Oxlfair’  ^  ^0  with  all  events 

not  of  the  form  in(e)/out(e)  removed,  and  the  events  in(e)/out(e)  in  tt 
are  all  unique  }. 

The  semantics  of  a  top-level  diagram,  {D^J,  is  then 
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where  e  0  /i,  x'  =  xU  (acg(e)  -  p),  pkt{e)  is  not  keyed,  target{e)  E  p,  and 
{acq{D)  U  acq{p))  fl  acq(e)  Q  pUx 


L)^(/xU{e}) 


where  e  ^  p,  p*  =  pli  (acq(e))  —  x),  pkt(e) 
i?[skip;  p 
i?[skip  II  skip]^  p 
R[Di®DrY^p 


par^ 

choose(2) 


is  not  keyed,  and  target{e)  E  x 

ijpK  II 

i?[3kip]^  It 

>  fliAi;  li 


and  similarly  for  choose(r) 

E[f  ork(£>)]J  p  ^  (ii:[skip]  II  R'[D]y^  p 

where  for  R  =  i^o  ['Oti  =  •  •  •  [il7n  :  •■•  |}],  -R'  =  -(Iti  :•••  fl7n  4 

J?[receive(aci  <  Mi{  :  ^})]x  (a*  *-*  {e})  -4i?'[skip]^  p 

where  R'  =  R@  x  :=  s,  and  pkt{e)  —  ad{e{R))  <  Md{e{R')){  :  k} 
il[send(ad  <  Md{  :  k})]^  p  jen^  i2[skip]^  {p  U  {e}) 

where  pkt{e)  =  ad{€{R))  <  Md{e{R)){  :  k}  and  e  is  a  fresh  event 
i2[new(a:)]^ //  (J?  ©  rc  :=  s)[skip]J /i 

where  acq{s)  C  p  U  x  U  acq{R)  U  acq{p) 
i2[fresh(a;)]^  p  [R^x  :=  s)[skip]^  p 

where  a  ^  p  U  x  U  ocg(i?[skip])  U  acq{p) 
i2[constrain((/i)]^ //  constrain^  i^[skip]^  p 

where  (f>{p,  x,  e(f?))  holds 

R[x  —tpY^p  (i?'[skip] J  p 

where  R*  =  R@x  ’.=  ij){p,Xi £(-R))]  7^  [  ] 
i?[recX.£>]J  p  ^^^^^^R[D[{r%cX.D)/X]Y^  p 

R[{D}Y^p  i?[fl(Arr.±)  : 

i2[{|7  :  skipfrK ^^^^R[sl^il>Y^p 


Fig.  2.  Single-Step  Computation  for  Diagrams 
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4.3  Commentary  on  the  Definition 

The  single-step  computation  rules  themselves  are  for  the  most  part  familiar 
territory  for  operational  semantics  presentations,  with  a  few  different  aspects. 
They  represent  a  language  with  syntax  something  like  CSP,  and  asynchronous 
message  passing  and  name  handling  modelled  on  the  actor  approach.  We 
provide  some  commentry  on  what  are  perhaps  some  of  the  nonstandard  aspects 
of  the  rules. 

The  pair  rule  could  just  as  well  map  skip  ||  D  to  D.  The  receive  rule 
contains  implicit  pattern-matching.  Diagram  variables  in  are  considered 
pattern  variables,  and  are  matched  against  the  event  e.  Note  that  the  receiver 
Od  could  itself  be  a  diagram  variable,  but  this  is  not  considered  part  of  the 
pattern:  it  is  not  possible  to  receive  a  message  destined  for  an  arbitrary  actor. 
acq{s)  C  acq{e)  holds  by  the  pattern  match.  In  both  send  and  receive,  the  keys 
K  are  not  “«:d”-they  are  simple  constants  and  cannot  be  variables  which  are 
defined  in  the  environment.  The  new  rule  allocates  variable  x  at  the  current 
lexical  scoping  level,  and  gives  it  an  arbitrary  value  based  on  the  names  of 
actors  currently  known,  fresh,  on  the  other  hand,  assigns  a  single  actor  name 
to  X  which  is  not  currently  known.  In  either  rule,  if  x  were  already  declared 
within  the  current  lexical  level,  the  old  value  is  replaced,  assign  updates  a 
variable  based  on  The  side  condition  only  fails  for  the  case  a  variable  is 
assigned  to  which  was  never  declared;  this  will  cause  the  computation  to  get 
stuck  and  thus  ruled  out  by  lack  of  progress,  constrain  only  continues  to 
compute  when  the  constraint  holds;  if  not  the  computation  is  stuck  and  is 
ruled  out  by  the  progress  requirement. 

The  most  unusual  aspect  of  the  semantics  lies  in  the  details  of  the  progress 
requirement.  This  requirement  is  significantly  stronger  than  standard  fairness 
requirements,  and  makes  the  computation  system  unrealizable.  In  fact,  even 
without  requiring  progress  the  computation  system  is  unrealizable  because 
predicates  <f>{p,  x?  £)  may  be  undecidable,  and  thus  for  instance  a  deterministic 
halting-problem  solver  may  be  defined.  However,  assuming  predicates  must 
be  decidable,  the  progressing  paths  still  may  not  be  realized  by  some  actor 
computation.  An  example  of  such  a  non-realizable  diagram  is: 

new(nomorezeros  =  false); 

[  {receive(a<0);  constrain(-'nomorezeros); 
nomorezeros  :=true;  send(c<il)) 

© 

(receive (a  <1  x);  constrain(-i(x  =  0  A  nomorezeros)); 
send(c<iO))  ]°  '°° 

it  replies  0  to  all  inputs,  except  the  last  0  input  may  get  a  1  reply.  No  real- 
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izable  system  can  forsee  the  future  to  know  when  the  last  input  of  a  particular 
form  has  arrived. 

Progress  rules  out  any  computation  path  which  contains  a  parallel  compu¬ 
tation  that  is  stuck,  ie.,  does  not  reduce.  The  phrase  “subterm  occurrence”, 
in  analogy  to  the  concept  of  residual  in  the  lambda-calculus,  denotes  a  partic¬ 
ular  occurrence  of  a  subterm,  because  the  same  syntax  may  in  theory  occur 
multiple  times  in  a  single  term.  Each  ocurrence  must  progress.  A  fully  formal 
definition  may  be  obtained  by  decorating  each  subterm  with  a  unique  label. 
Particular  computation  paths  that  progress  rules  out  include 

•  paths  with  false  constraints  such  as  i?[constrain(a;  =  0)]^/i  where  R@x  = 

1; 

•  paths  which  attempt  receipt  of  a  message  on  an  unused  local  actor  name, 
such  as  i?[receive(o <  Md{  :  k})]^  0  for  actor  a  ^  pUx  that  is  never  sent 
out  of  the  configuration  and  which  is  sent  no  messages  locally; 

•  paths  which  attempt  receipt  of  a  message,  i?[receive(a  <  Md{  :  k})]^  0 
where  in  this  particular  computation  path  the  environment  will  in  no  such 
message  and  it  will  not  be  sent  locally  either; 

•  paths  which  attempt  receipt  of  a  message  on  an  external  actor  name,  or 
send  of  a  keyed  packet  to  an  external  actor; 

•  assignments  to  variables  that  do  not  exist  in  the  environment,  R[x  :  =  0]^  p 
for  R@x  =  ±. 

The  above  cases  (excepting  the  first)  are  often  a  product  of  an  ill-conceived 
diagram  design.  However,  There  is  no  firm  line  that  may  be  drawn  between 
the  well-conceived  and  ill-conceived  diagrams:  well-conceived  diagrams,  when 
composed  with  other  diagrams,  may  appear  ill-conceived.  Nonetheless  a  sim¬ 
ple  conservative  aproximation  of  ill-conceived  diagrams  is  possible  that  detects 
many  obvious  errors. 

Definition  4.4  A  diagram  is  ill-conceived  if  =  0.  Other  diagrams 
besides  these  may  reasonably  be  classified  as  ill- conceived. 

If  a  diagram  has  no  paths,  it  cannot  be  sensible.  There  are  other  diagrams 
which  are  intuitively  not  sensible,  but  there  is  no  firmer  line  that  can  be  drawn 
between  sensible  and  not.  Consider  D  that  contain  a  subterm  occurrence 
Di  ©  Dr  for  which  all  computation  paths  in  either  invariably  reduce 

this  occurrence  redex  by  choice(i),  or  invariably  by  choice(r).  These  choice 
operators  may  thus  be  simplified  away  to  the  always-chosen  case  only,  and  this 
may  be  due  to  an  ill-conceived  expression  in  the  case  never  taken.  However, 
it  could  also  be  due  to  the  fact  that  in  the  context  the  subterm  occurs  in, 
the  path  not  taken  is  not  used,  because  the  specification  is  more  general  than 
the  current  usage.  For  this  reason,  such  cases  are  not  invariably  classified  as 
ill-conceived. 
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An  example  which  shows  a  need  for  keys  is 

new(a;);  ((x  :=  1;  send(o  <ia; :  k)  0  a:  :  =  2;send(o<x  :  k'))  || 

(receive(a  <a; :  /c)0 

(receive (a  <x  :  k')]  (skip  0  (constrain(a:  7^  2);  send(a  <iBAD)))))) 

— if  the  keys  were  removed,  a  k-k'  communication  could  occur  and  BAD  could 
be  sent  to  a. 

5  Toward  an  Algebra  of  Diagrams 

We  now  outline  the  algebra  of  diagrams;  work  remains  to  be  done  in  this  area. 
See  [Tal97]  for  full  definition  of  the  algebra  of  interaction  path  sets;  basic 
definitions  were  given  previously  in  section  3.  The  algebra  on  diagrams  is 
directly  lifted  from  the  algebra  on  Ip  sets  vie  the  semantic  meaning  function 
for  diagrams,  When  performing  algebraic  reasoning  on  diagrams,  we 

use  the  convention  that  in  fact  stands  for  its  interaction  path  semantics, 
[D^J.  The  algebraic  operations  on  diagrams  are  inherited  from  the  algebraic 
operations  on  interaction  path  sets: 

Definition  5.1  (Composition,  Restriction,  Renaming) 

^1X1  II  ^2^2  PlxJ  II 

DP\f/  means 
a{D^)  means  S([Z>^]) 

The  notion  of  equivalence  desired  for  top-level  diagrams  is  an  extensional  one: 
we  are  not  interested  in  internal  structure  of  the  diagrams,  only  that  an  actor 
configuration  satisfies  one  specification  if  and  only  if  it  satisfies  another.  Thus 
two  diagrams  are  defined  to  be  equivalent  when  their  interaction  paths  are  the 
same. 

Definition  5.2  (Extensional  Equivalence  of  Diagrams)  iff 

[A£]  =  |I52gI. 

Note  that  we  use  =  for  extensional  equivalence,  reserving  =  for  syntactic 
identity  of  diagrams. 

The  composition  of  top-level  diagrams  is  achieved  just  by  forming  a  new 
diagram  which  places  the  composed  diagrams  in  parallel.  This  allows  for  mod¬ 
ular  construction  of  diagrams  and  modular  reasoning  about  diagram  proper¬ 
ties. 

Theorem  5.3 

A?,  II  ^  ({Di}  II  {r>2})(£ll  £). 
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provided^^  txi  and  for  each  Teceive{a^,  mp^)  occurring  in  Di,  hy  inspection, 
Od  ^  P2)  o,nd  similarly  for  D2. 

The  “by  inspection”  condition  perhaps  needs  elaborating.  One  conservative 
interpretation  would  be  that  either  Od  =  o  for  a  G  pi,  or  Od  =  a:  and  £{x)  G  pi 
for  all  s  arising  in  This  condition  is  needed  to  guarantee  messages 

are  destined  for  one  component  or  the  other,  and  not  both.  In  section  2 
the  FunctionComposer  uses  this  theorem  to  show  its  components  may  be 
defined  as  separate  top-level  diagrams  and  composed.  After  components  are 
composed,  send  and  receive  messages  between  the  two  components  may  be 
matched  to  give  send-receive  edges.  The  function  composer  example  also 
illustrates  this  transformation.  A  future  goal  is  a  fully  rigorous  justification 
of  this  operation. 

Restriction  is  elementary  if  newly  restricted  receptionists  were  in  fact  sent 
no  messages  in  the  specification: 

Lemma  5.4 

provided  for  each  receive(ad)  “f^Pd)  occurring  in  D,  hy  inspection,  Od  ^  pi- 

What  is  defined  here  is  equivalence  on  top-level  diagrams.  In  general  it 
will  be  desirable  to  define  equivalance  on  diagram  fragments;  the  natural  idea 
is  to  use  some  sort  of  contextual  equivalence  a  la  Plotkin.  We  leave  that  topic 
for  future  work. 

6  Related  Work 

There  are  a  wide  variety  of  notations  for  concurrent/distributed  system  spec¬ 
ification.  Different  forms  of  specification  have  different  strengths  and  weak¬ 
nesses,  and  for  large  systems  a  number  of  different  techniques  will  probably 
be  needed  in  parallel.  We  briefiy  review  some  of  the  current  schools  by  way 
of  background. 

Process  Algebras 

Process  algebra  notation  may  be  used  to  formally  specify  the  communica¬ 
tion  actions  of  concurrent  systems,  and  this  was  in  fact  one  of  the  original  goals 
of  CCS  [Mil80].  Process  algebra  and  specification  diagrams  in  fact  share  some 
significant  similarities.  Parallel  composition  is  of  a  similar  sort  in  both;  choice 
in  specification  diagrams  could  be  viewed  as  a  generalization  of  CCS’  external 
choice  operator,  message  send  and  receive  is  analogous  to  the  related  con¬ 
cepts  in  the  7r-calculus  [MPW92,HT91],  although  the  7r-calculus  restricts  data 
passed  to  be  a  channel  name,  and  is  in  the  classical  presentation,  synchronous 
as  opposed  to  asynchronous.  Name-passing  and  dynamic  name  creation  are 
important  to  distributed  systems  and  are  treated  in  specification  diagrams 
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as  well  as  the  vr  calculus.  The  trace-based  semantic  framework  is  a  concept 
shared  with  CSP  [Hoa85]. 

There  are  differences  as  well,  and  the  most  important  ones  are  found  be¬ 
neath  the  surface  in  the  semantics  of  operators  and  not  their  syntax.  The 
object-based  behavior  of  specification  diagrams  is  enforced  by  the  interfaces; 
for  this  there  is  no  analogue  in  process  algebra  since  it  is  not  object-based. 
There  is  a  subtle  difference  in  the  meaning  given  to  specification  diagrams  in 
comparison  to  process  algebra.  Simply  put,  process  algebra  is  given  a  purely 
operational,  realizable,  interpretation.  Even  though  specification  diagrams 
have  an  operational  semantics,  this  semantics  is  not  realizable.  If  a  constraint 
fails  during  computation,  the  computation  never  happened]  it  disappears  from 
the  set  of  possible  paths.  Constraints  themselves  may  not  be  decidable  prop¬ 
erties.  Specifications  written  in  process  algebra  notation  admit  the  possibility 
of  deadlock  since  the  environment  may  not  send  a  particular  desired  message. 
Specification  diagrams,  on  the  other  hand,  constrain  the  environment  so  that 
deadlock  implicitly  cannot  occur;  instead,  either  a  specification  is  ill-formed, 
or  composition  of  specifications  will  fail.  Deadlock  can  in  fact  be  specified 
in  specification  diagrams,  by  actively  ignoring  all  input.  The  Sink  example 
earlier  is  such  an  example.  Specification  diagrams  allow  communication  to  be 
constrained  both  at  send  and  receive  by  cross-edges,  so  operationally  speaking, 
if  a  message  is  not  received  by  its  intended  receiver,  that  computation  path 
never  happened.  There  are  advantages  and  disadvantages  of  uncomputable 
specification  languages.  The  main  advantage  of  uncomputable  languages  is 
their  expressivity.  The  main  advantage  of  computable  languages  is  they  gen¬ 
erally  possess  more  decidable  properties. 

Choice  in  specification  diagrams  could  be  called  “extremely  external”  if 
the  nomenclature  of  internal/external  choice  of  CCS  is  used.  Internal  choice 
is  a  random  coin  flip  which  irrevocably  picks  one  of  two  paths.  External  choice 
in  its  general  form  is  a  guarded  choice;  the  path  chosen  must  have  the  guard 
condition  holding.  In  specification  diagrams,  the  constraints  allow  a  choice  to 
be  “un-chosen”  even  after  it  had  been  started,  not  just  at  the  beginning.  This 
is  not  an  operational  notion,  but  is  useful  in  certain  cases  to  allow  for  succinct 
specification  of  concurrent  object  behavior. 


in(ad<x);  (out(ad<a:);  in(od<y);  constrain(y  >  0))  ©  skip 


-This  specification  has  odd  behavior  of  only  forwarding  a  message  when  the 
next  message  is  a  positive  number. 

A  number  of  full  specification  languages  based  on  process  algebra  have 
been  developed;  examples  include  LOTOS  [BB87],  which  is  based  on  CSP; 
it  is  now  an  an  ISO  standard.  Esterel  [BG92]  is  a  process  algebra  based 
specification  language  with  a  synchronous  execution  semantics. 

23 


Smith 


Temporal  Logic 

Temporal  logic  formulae  have  been  extensively  used  as  a  means  for  logi¬ 
cal  specification  of  concurrent  and  distributed  systems  [JM86,MP92,Lam94]. 
While  logics  may  express  an  extremely  broad  collection  of  properties,  a  signifi¬ 
cant  disadvantage  is  the  need  for  large,  complex  formulae  to  specify  nontrivial 
systems:  readability  of  specifications  becomes  a  serious  issue  even  for  small 
specifications,  and  users  thus  require  more  advanced  training.  Specification 
diagrams  are  not  a  logic;  as  such,  they  cannot  logically  assert  global  proper¬ 
ties  of  programs,  only  local  properties  via  constraints.  The  equational  theory 
of  specification  diagrams  will  provide  the  basis  for  more  abstract  reasoning 
about  actor  system  components. 

Automata-Based  Formalisms 

Finite  automata  are  useful  for  specifying  systems  which  have  a  strong 
state-based  behavior.  They  lack  expressivity,  but  make  up  for  this  lack  by 
their  amenability  to  automatic  verification  by  state-space  search  techniques. 

The  StateCharts  formalism  [Har87]  has  become  particularly  popular  in  in¬ 
dustry.  States  of  the  automaton  represent  states  of  the  system  (where  certain 
invariant  properties  hold),  and  state  transitions  represent  actions.  The  Stat¬ 
eCharts  formalism  has  features  beyond  simple  finite  automata,  including  the 
ability  to  nest  and  compose  automata.  This  syntactic  sugar  makes  it  feasible 
to  write  specifications.  Automata  are  also  graphical  and  so  serve  as  good  vi¬ 
sual  specifications.  Their  primary  weakness  is  that  a  complex  software  system 
may  not  have  a  meaningful  global  state,  and  properties  of  such  systems  are 
more  naturally  expressed  in  terms  of  events  and  relations  on  events.  UML 
notation  includes  a  StateCharts-based  style  of  diagram.  A  formal  semantics 
of  StateCharts  has  been  defined  [HPPSS87],  but  the  tools  are  not  sound  with 
respect  to  a  formal  semantics  and  so  the  effort  is  not  completely  satisfactory. 

Message-Passing  Diagrams 

Message-passing  diagrams  are  a  common  form  of  informal  graphical  spec¬ 
ification.  A  message-passing  diagram  has  a  time-line  showing  the  message¬ 
passing  behavior  between  different  components.  Unlike  the  other  approaches 
described  above,  message  passing  specifications  are  usually  object-based  and 
can  be  asynchronous.  The  UML  Sequence  Diagram  [RJB98]  (derived  in  turn 
from  the  event  trace  diagram  of  [et  o/91])  is  a  simple  form  of  message  passing 
diagram  for  rpc-style  communication.  Specfication  diagrams  can  be  viewed  as 
a  major  extension  of  UML  sequence  diagram  notation.  In  the  actor  model, 
event  diagrams  [Gre75,Hew77]  model  actor  computation  in  terms  of  message¬ 
passing  between  actors.  Clinger[Cli81]  formalizes  event  diagrams  as  math¬ 
ematical  structures  and  defines  a  formal  semantics  mapping  actor  system 
descriptions  to  sets  event  diagrams.  More  generally  sets  of  event  diagrams 
can  be  thought  of  as  abstract  specifications.  These  have  rich  mathematical 
structure  but,  are  in  general  highly  undecidable.  Specification  diagrams  were 
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partly  inspired  by  event  diagrams,  and  can  be  viewed  as  a  condensation  of 
a  possibly  infinite  set  of  possibly  infinite-sized  event  diagrams  to  one,  finite, 
representation. 
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There  are  two  distinct  areas  of  work  in  mobility:  mobile  computing,  con¬ 
cerning  computation  that  is  carried  out  in  mobile  devices  (laptops,  personal 
digital  assistants,  etc.),  and  mobile  computation,  concerning  mobile  code  that 
moves  between  devices  (applets,  agents,  etc.).  We  aim  to  describe  all  these 
aspects  of  mobility  within  a  single  framework  that  encompasses  mobile  agents, 
the  ambients  where  agents  interact  and  the  mobility  of  the  ambients  them¬ 
selves. 

This  extended  abstract  of  a  longer  paper  [2]  presents  a  minimal  calculus 
of  ambients  that  includes  only  mobility  primitives.  Section  1  gives  its  syntax 
and  introduces  its  semantics  informally.  Section  2  gives  a  formal  semantics. 
Section  3  concludes. 


1  Syntax  and  Informal  Semantics 


We  begin  by  defining  the  syntax  of  the  calculus  in  the  following  table.  The 
main  syntactic  categories  are  processes  (including  ambients  and  agents  that 
execute  actions)  and  capabilities. 


Mobility  and  Communication  Primitives 

I - - 


in  n 
out  n 
open  n 


P,Q,R::^ 

{vn)P 


names 

capability 

can  enter  into  n 
can  exit  out  of  n 
can  open  n 
process 

restriction 
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0 

inactivity 

P\Q 

composition 

IP 

replication 

n[P] 

ambient 

M.P 

action 

- - — - — - - - ' 

The  first  four  process  primitives  (restriction,  inactivity,  composition  and 
replication)  have  the  same  meaning  as  in  the  7r-calculus  [4]  namely:  restriction 
is  used  to  introduce  new  names  and  limit  their  scope;  0  has  no  behavior;  P  \  Q 
is  the  parallel  composition  of  P  and  Q;  and  !P  is  an  unbounded  number  of 
parallel  replicas  of  P.  The  main  difference  with  respect  to  the  7r-calculus  is 
that  names  are  used  to  name  ambients  instead  of  channels.  To  these  standard 
primitives  we  add  ambients,  n[P],  and  the  exercise  of  capabilities,  M.P . 

We  now  introduce  the  semantics  of  ambients  informally.  A  reduction  rela¬ 
tion  P  Q  describes  the  evolution  of  a  process  P  into  a  new  process  Q. 

Ambients 

An  ambient  is  written  n[P],  where  n  is  the  name  of  the  ambient,  and  P  is  the 
process  running  inside  the  ambient.  In  n[P],  it  is  understood  that  P  is  actively 
running,  and  that  P  can  be  the  parallel  composition  of  several  processes.  We 
emphasize  that  P  is  running  even  when  the  surrounding  ambient  is  moving. 
Running  while  moving  may  or  may  not  be  realistic,  depending  on  the  nature 
of  the  ambient  and  of  the  communication  medium  through  which  the  ambient 
moves,  but  it  is  consistent  to  think  in  those  terms. 

In  general,  an  ambient  exhibits  a  tree  structure  induced  by  the  nesting  of 
ambient  brackets.  Each  node  of  this  tree  structure  may  contain  a  collection  of 
(non-ambient)  processes  running  in  parallel,  in  addition  to  subambients.  We 
say  that  these  processes  are  running  in  the  ambient,  in  contrast  to  the  ones 
running  in  subambients. 

Nothing  prevents  the  existence  of  two  or  more  ambients  with  the  same 
name,  either  nested  or  at  the  same  level.  Once  a  name  is  created,  it  can  be  used 
to  name  multiple  ambients.  Moreover,  !n[P]  generates  multiple  ambients  with 
the  same  name.  This  way,  for  example,  one  can  easily  model  the  replication 
of  services. 

Operations  that  change  the  hierarchical  structure  of  ambients  are  sensitive. 
In  particular  such  operations  can  be  interpreted  as  the  crossing  of  firewalls  or 
the  decoding  of  ciphertexts.  Hence  these  operations  are  restricted  by  capabil¬ 
ities.  Thanks  to  capabilities,  an  ambient  can  allow  other  ambients  to  perform 
certain  operations  without  having  to  reveal  its  true  name. 

Actions  and  Capabilities 

The  process  M.P  executes  an  action  regulated  by  the  capability  M,  and  then 
continues  as  the  process  P.  The  process  P  does  not  start  running  until  the 
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action  is  executed.  The  reduction  rules  for  M.P  depend  on  the  capability  M, 
and  are  described  below  case  by  case. 

We  consider  three  kinds  of  capabilities:  one  for  entering  an  ambient,  one 
for  exiting  an  ambient  and  one  for  opening  up  an  ambient.  Capabilities  are 
obtained  from  names;  given  a  name  n,  the  capability  in  n  allows  entry  into  n, 
the  capability  out  n  allows  exit  out  of  n  and  the  capability  open  n  allows  the 
opening  of  n.  Implicitly,  the  possession  of  one  or  all  of  these  capabilities  for 
n  is  insufficient  to  reconstruct  the  original  name  n. 

An  entry  capability,  mm,  can  be  used  in  the  action  inm.P,  which  instructs 
the  ambient  surrounding  in  m.P  to  enter  a  sibling  ambient  named  m.  If  no 
sibling  m  can  be  found,  the  operation  blocks  until  a  time  when  such  a  sibling 
exists.  If  more  than  one  m  sibling  exists,  any  one  of  them  can  be  chosen.  The 
reduction  rule  is: 

n[in  m.P  \  Q]  \  m[R]  m[n[P  |  Q]  1  jR] 

If  successful,  this  reduction  transforms  a  sibling  n  of  an  ambient  m  into 
a  child  of  m.  After  the  execution,  the  process  in  m.P  continues  with  P,  and 
both  P  and  Q  find  themselves  at  a  lower  level  in  the  tree  of  ambients. 

An  exit  capability,  out  m,  can  be  used  in  the  action  out  m.P,  which 
instructs  the  ambient  surrounding  out  m.P  to  exit  its  parent  ambient  named 
m.  If  the  parent  is  not  named  m,  the  operation  blocks  until  a  time  when  such 
a  parent  exists.  The  reduction  rule  is: 

m[n[out  m.P  |  Q]  |  P]  — n[P  |  Q]  \  m[R] 

If  successful,  this  reduction  transforms  a  child  n  of  an  ambient  m  into  a 
sibling  of  m.  After  the  execution,  the  process  in  m.P  continues  with  P,  and 
both  P  and  Q  find  themselves  at  a  higher  level  in  the  tree  of  ambients. 

An  opening  capability,  open  n,  can  be  used  in  the  action  open  n.P.  This 
action  provides  a  way  of  dissolving  the  boundary  of  an  ambient  named  n 
located  at  the  same  level  as  open  n.P,  according  to  the  rule: 

open  n.P  \  n[Q]  ->  P  ]  Q 

If  no  ambient  n  can  be  found,  the  operation  blocks  until  a  time  when  such 
an  ambient  exists.  If  more  than  one  ambient  n  exists,  any  one  of  them  can  be 
chosen. 

2  Formal  Semantics 

We  now  give  an  operational  semantics  of  our  calculus,  based  on  a  structural 
congruence  between  processes,  =,  and  a  reduction  relation  — This  is  a 
semantics  in  the  style  of  Milner’s  reaction  relation  [3]  for  the  7r-calculus,  which 
was  itself  inspired  by  the  Chemical  Abstract  Machine  of  Berry  and  Boudol  [1] . 

We  let  structural  congruence,  =,  be  the  least  relation  on  processes  that 
satisfies  the  following  equations  and  rules: 
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Structural  Congruence 


p  =  p 

P\Q  =  Q\P 

Q  =  P  P  =  Q 

(.P\Q)\R  =  P\(Q\R) 

P  =  Q,Q  =  R=^P  =  R 

!P  =  P  1  !P 

{un){um)P  =  {um){un)P 

P  =  Q  {vn)P  =  {vn)Q 

{un){P  1  Q)  =  P  1  {i^n)Q  fn{P) 

P  =  Q=^P\R  =  Q\  R 

{un){m[P])  =  m[{un)P]  if  n  ^  m 

P  =  Q^\P  =  \Q 

P  10  =  P 

P  =  Q  n[P]  =  n[Q] 

(i/n)0  =  0 

P  =  Q=^  M.P  =  M.Q 

1 _ 

!0  =  0 

- -J 

We  let  the  reduction  relation,  — be  the  least  relation  on  processes  to 
satisfy  the  following  rules: 

Reduction _ 

n[in  m.P  \  Q]  \  m[R]  — >•  m[n[P  |Q]|i2]  P^Q^P\R-^Q\R 

m[n[out  m.P  |  Q]  |  i?]  — >•  n[P  |  Q]  |  m[R]  P  Q  ^  {un)P  {i'n)Q 

open  n.P  \  n[Q\  —^P\Q  P  Q  =>  n[P]  — >•  n\Q\ 

P' =  P,P--^Q,Q  =  Q'  =^P’  ^Q' 


3  Summary 

We  presented  the  syntax  and  semantics  of  a  minimal  calculus  of  ambients. 
In  the  full  paper  [2]  we  provide  more  motivation  and  intuition,  investigate  a 
calculus  with  additional  primitives  for  I/O,  survey  related  work  and  include 
many  examples.  We  discuss  how  the  notion  of  a  mobile  ambient  captures  the 
structure  of  complex  networks  and  the  behavior  of  mobile  computation.  The 
full  calculus  is  no  more  complex  than  common  process  calculi,  but  supports 
reasoning  about  mobility  and,  at  least  to  some  degree,  security. 
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Abstract 

In  the  standard  Java  implementation,  a  Java  language  program  is  compiled  to 
Java  bytecode  and  this  bytecode  is  then  interpreted  by  the  Java  Virtual  Machine. 
Since  bytecode  may  be  written  by  hand,  or  corrupted  during  network  transmission, 
the  Java  Virtual  Machine  contains  a  bytecode  verifier  that  performs  a  number  of 
consistency  checks  before  code  is  interpreted.  As  one-step  towards  a  formal  specifi¬ 
cation  of  the  verifier,  we  describe  a  precise  specification  of  a  subset  of  the  bytecode 
language  dealing  with  object  creation  and  initialization. 


1  Introduction 

The  Java  programming  language  is  a  statically-typed  general-purpose  pro¬ 
gramming  language  with  an  implementation  architecture  that  is  designed  to 
facilitate  transmission  of  compiled  code  across  a  network.  In  the  standard 
implementation,  a  Java  language  program  is  compiled  to  Java  bytecode  and 
this  bytecode  is  then  interpreted  by  the  Java  Virtual  Machine.  The  interme¬ 
diate  bytecode  language,  which  we  refer  to  as  JVML,  is  a  typed,  machine- 
independent  form  of  assembly  language  with  some  low-level  instructions  that 
reflect  specific  high-level  Java  source  language  constructs.  For  example,  classes 
are  a  basic  notion  in  JVML.  Since  bytecode  may  be  written  by  hand,  or 
corrupted  during  network  transmission,  the  Java  Virtual  Machine  contains  a 
bytecode  verifier  that  performs  a  number  of  consistency  checks  before  code  is 
interpreted.  This  protects  the  receiver  from  certain  security  risks  and  various 
forms  of  attack. 

In  this  summary,  we  describe  a  specification  for  a  fragment  of  the  bytecode 
language  that  includes  object  creation  (allocation  of  memory)  and  initializa¬ 
tion  in  terms  of  a  type  system.  This  work  is  based  on  a  prior  study  of  the 

@1998  Published  by  Elsevier  Science  B.  V. 


Freund  and  Mitchell 


bytecodes  for  local  subroutine  call  and  return  [2]. 

2  Object  Initialization 

As  in  many  other  object-oriented  languages,  the  Java  implementation  creates 
new  objects  in  two  steps.  The  first  step  is  to  allocate  space  for  the  object.  This 
usually  requires  some  environment  specific  operation  to  obtain  an  appropriate 
region  of  memory.  In  the  second  step,  user-defined  code  is  executed  to  initialize 
the  object.  In  Java,  the  user  initialization  code  is  provided  by  a  constructor 
defined  in  the  class  of  the  object.  Only  after  both  of  these  steps  are  completed 
can  a  method  be  invoked  on  an  object. 

In  the  Java  source  language,  allocation  and  initialization  are  combined  into 
a  single  statement.  This  is  illustrated  in  the  following  code  fragment: 

Point  p  =  new  Point (3) ; 
p. Print  0 ; 

Since  every  Java  object  is  created  by  a  statement  like  the  one  in  the  first  line 
here,  it  does  not  seem  difficult  to  prevent  Java  source  language  programs  from 
invoking  methods  on  objects  that  have  not  been  initialized. 

It  is  much  more  difficult  to  recognize  initialization-before-use  in  bytecode. 
This  can  be  seen  by  looking  at  the  five  lines  of  bytecode  that  are  produced  by 
compiling  the  two  lines  of  source  code  above: 

1:  new  #1  <Class  Point> 

2:  dup 
3:  iconst_3 

4:  invokespecial  #4  <Method  Point (int)> 

5:  invokevirtual  #5  <Method  void  Print ()> 

The  most  striking  difference  is  that  memory  allocation  (line  1)  is  separated 
from  the  constructor  invocation  (line  4)  by  two  lines  of  code.  The  first  inter¬ 
vening  line,  dup,  duplicates  the  pointer  to  the  uninitialized  object.  This  line 
is  needed  due  to  the  calling  convention  of  the  Java  Virtual  Machine.  The  sec¬ 
ond  line,  iconst_3,  pushes  the  constructor  argument  3  onto  the  stack.  If  the 
constructor  arguments  for  more  complicated,  many  more  lines  of  code  would 
appear  between  lines  (1)  and  (4). 

Since  pointers  may  be  duplicated,  as  above,  and  there  may  be  more  than 
one  uninitialized  object  present  at  any  time,  some  form  of  aliasing  analysis 
must  be  used.  Sun’s  Java  Virtual  Machine  Specification  [1]  describes  the  alias 
analysis  used  by  the  Sun’s  JDK  verifier.  For  each  line  of  the  bytecode  program, 
some  status  information  is  recorded  for  every  local  variable  and  stack  location. 
When  a  location  points  to  an  object  that  is  not  known  to  be  initialized  in 
all  executions  reaching  this  statement,  the  status  will  include  not  only  the 
property  uninitialized,  but  also  the  line  number  on  which  the  uninitialized 
object  would  have  been  created.  As  references  are  duplicated  on  the  stack 
and  stored  and  loaded  in  the  local  variables,  the  analysis  also  duplicates  these 
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(new) 


P[i]  =  new  ex 
Fi+l  —  Pi 

iSj+i  =  •  Si 


»i^Si 

Vj/  e  Dom{Fi).  Fi[y]  #  CTj 
i  +  1  €  Dom{P) 


F,S,i\-P 


(init) 


(use) 


P[i]  =  use  <7 
Fi+i  =  Fi 
Si  —  ex  •  5i+i 
i  + 1  €  Dom{P) 
F,S,i\-P 


P[i]  =  init  a 
Fi+i  =  [exlaj]Fi 
Si  =  Uj  -  a 
Si+i  =  [exldj]a 
j  e  Dom{P) 
i  +  1  G  Dom{P) 
F,S,i\-P 


Fig.  1.  Static  semantics. 


line  numbers.  All  references  having  the  same  line  number  are  assumed  to  refer 
to  the  same  object.  When  an  object  is  initialized,  all  pointers  that  refer  to 
objects  created  at  the  same  line  number  are  set  to  initialized.  In  other  words, 
all  references  to  objects  of  a  certain  type  are  partitioned  into  equivalence 
classes  according  to  what  is  statically  known  about  each  reference. 

Since  our  approach  is  type  based,  the  status  information  associated  with 
each  reference  for  the  alias  analysis  is  recorded  as  part  of  its  type. 


3  JVMLi 

Our  study  uses  JVMLi,  an  idealized  subset  of  JVML  encompassing  basic  con¬ 
structs  and  object  initialization.  This  section  introduces  JVMLj  and  describes 
the  typing  rules  performing  the  alias  analysis  described  in  the  previous  sec¬ 
tion.  In  this  summary,  we  present  only  those  instructions  related  to  object 
initialization: 

new  a:  allocates  a  new,  uninitialized  object  of  type  a. 

init  cr:  initializes  a  previously  uninitialized  object  of  type  a.  This  represents 
calling  the  constructor  of  an  object. 

use  a:  performs  an  operation  on  an  initialized  object  of  type  o.  This  corre¬ 
sponds  to  several  operations  in  JVML,  including  method  invocation  (in- 
vokevirtual),  accessing  an  instance  field  (putf  ield/getf  ield),  etc. 


3.1  Typing  Rules 

A  program  is  represented  by  an  array  of  instructions.  A  program  P  is  well 
typed  if  there  exist  F  and  S  such  that 

F,S\-P, 

where  F  is  a  vector  of  functions  mapping  local  variables  to  types  such  that 
Fi[y]  is  the  type  of  local  variable  y  at  line  i  of  a  program.  Likewise,  5  is  a 
vector  of  stack  types  such  that  Si  is  the  type  of  the  operand  stack  at  location 
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i  of  the  program.  The  judgment  which  allows  us  to  conclude  that  a  program 
P  is  well  typed  by  F  and  S  is 

Fi  =  Ftop 
Si  =  e 

Vi  €  Dom{P).  F,S,i\-  P 
ywt  pvog)  ^  ^  jp 

where  Ftop  is  a  function  mapping  all  variables  to  Top,  the  type  of  unusable 
values.  The  first  two  lines  of  {wt  prog)  constrain  the  initial  conditions  for 
the  program’s  execution.  The  third  line  requires  that  each  instruction  in  the 
program  is  well  typed  according  to  local  judgments  for  each  instruction.  The 
rules  for  those  instructions  dealing  with  object  initialization  are  presented 
in  Figure  1,  where  a  is  some  object  type  and  is  the  type  given  to  an 
uninitialized  object  of  type  a  allocated  on  line  i  of  P.  A  soundness  result  is 
stated  and  discussed  in  the  full  version  of  this  paper. 

4  Discussion 

Given  the  need  to  guarantee  type  safety  for  mobile  Java  code,  developing 
correct  type  checking  and  analysis  techniques  for  JVML  is  crucial.  We  have 
built  on  the  previous  work  of  Stata  and  Abadi  to  develop  such  a  specification 
by  formulating  a  sound  type  system  for  object  initialization.  Although  our 
model  is  still  rather  abstract,  it  has  already  proved  effective  as  a  foundation  for 
examining  both  JVML  and  existing  bytecode  verifiers.  In  fact,  a  previously 
unpublished  bug  in  Sun’s  verifier  implementation  was  found  as  a  result  of  the 
analysis  performed  while  studying  the  soundness  proofs  for  JVMLj  extended 
with  subroutines. 
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Communication  in  distributed  systems  often  relies  on  useful  abstractions 
such  as  channels,  remote  procedure  calls,  and  remote  method  invocations. 
The  implementations  of  these  abstractions  sometimes  provide  security  prop¬ 
erties,  in  particular  through  encryption  [7,6,9,8,5,12,13].  In  this  work  we  study 
those  security  properties,  focusing  on  channel  abstractions.  We  introduce  a 
simple  high-level  language  that  includes  constructs  for  creating  and  using  se¬ 
cure  channels.  The  language  is  a  variant  of  the  join-calculus  [4]  and  belongs 
to  the  same  family  as  the  pi-calculus  [11,10].  We  show  how  to  translate  the 
high-level  language  into  a  lower-level  language  that  includes  cryptographic 
primitives  (cf.  [1-3]).  In  this  translation,  we  map  communication  on  secure 
channels  to  encrypted  communication  on  public  channels.  We  obtain  a  cor¬ 
rectness  theorem  for  our  translation;  this  theorem  implies  that  one  can  rea¬ 
son  about  programs  in  the  high-level  language  without  mentioning  the  subtle 
cryptographic  protocols  used  in  their  lower-level  implementation. 

The  full  paper  will  appear  in  LICS’98. 
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Abstract 

We  have  designed  a  new  module  language  called  program  units.  Units  support 
separate  compilation,  independent  module  reuse,  cyclic  dependencies,  hierarchical 
structuring,  and  dynamic  linking.  In  this  paper,  we  present  untyped  and  typed 
models  of  units. 


1  Program  Fragments  and  Units 

Programmers  consume  code  fragments  to  create  programs,  and  produce  code 
fragments  for  other  programs.  When  managing  fragments  becomes  mechanis¬ 
tic,  programmers  write  programs  that  assemble  and  execute  these  fragments. 
Some  of  these  programs  launch  fragments  as  separate  processes.  Other  pro¬ 
grams  link  several  fragments  together  to  produce  a  new  program  fragment. 
And  some  programs  dynamically  link  fragments  into  an  already-running  pro¬ 
gram.  Especially  in  this  last  case,  the  distinction  between  the  program  and  the 
fragments  that  is  manages  begins  to  blur.  Unfortunately,  current  program¬ 
ming  languages  cannot  clearly  express  the  interaction  between  these  levels. 

Programming  with  fragments  requires  a  two-phase  view  of  execution:  link¬ 
ing  followed  by  evaluation.  This  separation  of  phases  is  important  because  it 
enables  the  separate  compilation,  analysis,  and  optimization  of  fragments.  It 
also  suggests  separate  programming  languages:  a  core  language  for  implement¬ 
ing  fragments  and  a  module  language  for  linking  them.  Much  of  the  recent 
work  on  modularity  (in  particular,  work  on  ML  modules  [2,10,11,15,16,18,23]) 
has  taken  this  two-language  view  and  focused  on  making  the  linking  language 
flexible. 

For  MzScheme  [7],  we  designed  and  implemented  an  extension  of  Scheme 
that  carefully  combines  the  core  programming  language  with  the  linking  lan¬ 
guage.  In  this  language,  code  fragments  called  units  are  first-class  values.  The 
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only  primitive  operations  on  units  are  linking  and  invocation,  which  preserves 
the  phase  separation  for  an  individual  unit,  but  programmers  can  exploit  the 
full  flexibility  of  the  core  language  for  the  application  of  these  operations. 

In  this  paper  we  present  a  typed  language  of  program  units  that  supports 

•  units  that  import  and  export  type  definitions  as  well  as  value  definitions; 

•  compound  units  that  link  several  units  together  and  hide  selected  details  of 
the  constituent  units; 

•  procedure  and  type  definitions  with  mutual  references  across  unit  bound¬ 
aries; 

•  dynamic  linking  of  units  into  a  running  program; 

•  separate  compilation  of  units;  and 

•  flexible  linking  that  allows  multiple  instances  of  a  unit  in  a  single  program. 

Units  accomodate  a  variety  of  core  languags,  such  as  ML,  Ada,  Modula-3, 
Java,  Scheme,  or  C.  Each  of  these  languages  can  benefit  by  incorporating 
the  unit  language:  ML’s  modules  disallow  mutually-recursive  type  or  function 
definitions;  linking  in  Ada,  Modula-3,  and  Java  is  inflexible  because  linking  is 
specified  within  a  package  and  relies  on  a  global  package  namespace;  ^  Scheme 
has  no  standard  module  system;  and  C,  like  most  languages,  lacks  a  standard 
mechanism  for  dynamic  linking. 

Section  2  provides  an  overview  of  programming  with  units,  and  Section  3 
defines  the  precise  type  checking  and  semantics  of  units.  Section  4  briefly 
considers  compilation  issues.  The  last  two  sections  relate  our  unit  language 
to  existing  module  languages,  and  put  this  work  into  perspective. 

2  Programming  with  Units 

The  following  sub-sections  illustrate  the  basic  design  elements  of  our  unit 
language  using  an  informal,  semi-graphical  language.  The  examples  assume  a 
core  language  with  lexical  bloacks  and  a  sub-language  of  types.  The  syntax 
used  for  the  core  language  mimics  that  of  ML. 

2.1  Defining  Units 

Figure  1  defines  a  unit  called  Database.  In  the  graphical  notation,  each  unit 
is  drawn  as  a  box  with  three  sections: 

•  The  top  section  lists  the  unit’s  imported  types  and  values.  The  Database 

^  With  class  loaders,  the  meaning  of  the  global  namespace  can  be  adjusted,  but  this  adjust¬ 
ment  must  be  described  indirectly  via  a  loader  object  rather  than  directly  in  the  language. 
Even  then,  using  hardwired  names  for  imported  packages  prevents  linking  a  single  package 
in  multiple  contexts. 
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unit  imports  the  type  info  (with  the  kind  Q)  for  data  stored  in  the  database, 
and  the  function  error  (with  the  type  str-^void),  for  error-handling. 

•  The  middle  section  contains  the  unit’s  type  and  value  definitions  and  an 
initialization  expression.  The  latter  performs  startup  actions  for  the  unit 
at  run-time.  The  Database  unit  defines  the  type  db  and  the  functions  new^ 
insert,  and  delete  (plus  some  other  definitions  that  are  not  shown).  Database 
entries  are  keyed  by  strings,  so  Database  initializes  a  hash  table  for  strings 
with  the  expression  strTable  :=  makeStringHashTableQ. 

•  The  bottom  section  enumerates  the  unit’s  exported  types  and  values.  The 
Database  unit  exports  the  type  db  and  the  functions  new,  insert,  and  delete. 


Database 


infoiiQ  ejTonstr->void 

type  db  =  •  •  • 

fun  newQ’.db  =  ■■■ 

fun  insert{d:db,  keyistr,  viinfo)  =  •  •  • 

fun  delete{d:db,  keyzstr)  =  ••• 

{strTable  :=  makeStringHashTable{))i\/o‘\d 
dbr.Q,  neti;:void— insert: dbxstrx  inf o—>vo\d  <ie/efe:d6xstr— >void 


}  imports 


definitions 


>  and 

expressions 


}  exports 


Fig.  1.  A  simple  database  unit 


In  a  statically-typed  language,  all  imported  and  exported  values  have  a 
type,  and  all  imported  and  exported  types  have  a  kind.  Imported  and  defined 
types  can  be  used  in  the  the  type  expressions  for  imported  and  exported 
values.  All  exported  variables  must  be  defined  within  the  unit,  and  the  type 
expression  for  an  export  must  use  only  imported  and  exported  types.  In 
Database,  both  the  imported  type  info  and  the  exported  type  db  are  used  in 
the  type  expression  for  insert  dbxstrxinfo—^vold. 

A  unit  is  specifically  not  a  record  of  values  (as  ML  structures  are  usually 
described).  A  unit  encapsulates  unevaluated  code,  much  like  the  “.o”  file 
created  by  compiling  a  C  module.  Before  a  unit’s  definitions  and  initialization 
expression  can  be  evaluated,  it  must  be  first  linked  with  other  units  to  resolve 
all  of  its  imports. 

2.2  Linking  Units 

In  the  graphical  notation,  units  are  linked  together  via  arrows  connecting  the 
exports  of  one  box  with  the  imports  of  another.  Linking  units  together  creates 
a  compound  unit,  as  illustrated  in  Figure  2  with  the  PhoneBook  unit.  This 
unit  links  Database  with  Numberinfo,  a  unit  that  implements  the  info  type  for 
phone  numbers.  The  error  function  is  not  yet  determined,  so  the  PhoneBook 
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unit  imports  error  and  passes  the  imported  value  on  to  Database.  All  of 
the  exported  types  and  values  of  Database  and  Numberinfo  are  re-exported 
by  PhoneBook,  except  the  delete  function  from  Database.  Since  the  delete 
function  is  not  exported,  it  is  hidden  to  clients  of  PhoneBook. 


PhoneBook 


erronstr^^void  | 

Numberinfo 

type  info  =  •  •  • 

fun  numInfo{n:\nt):info  =  •  •  • 

infoiiQ  numInfo:\nt—>info 

Datable  \  ^ 

\ _ 

error.str—^void 

\  \ 

dbii^l  new:yo\(i--^db  ins6rt:dbxstrxinfo-^vo\d  delete: dbxstr—^yo\d 

1  "i  _ 

_ _ 

db:^  new:y/o\d^db  insert:dbxstrxinfo-^vo\d 

infoiiQ  numInfo:\r\t-^info 

Fig.  2.  Linking  units  to  form  a  compound  unit 


A  complete  program  is  a  unit  (either  simple  or  compound)  without  im¬ 
ports.  Figure  3  defines  a  complete  interactive  phone  book  program,  Interac- 
tivePhoneBook,  which  links  PhoneBook  with  a  graphical  interface  implementa¬ 
tion  Gui  and  an  error  unit  ErrorHandler.  The  Main^  contains  an  initialization 
expression  that  creates  a  database  and  an  associated  grahical  interface. 

A  complete  program  is  analogous  to  an  executable  file  in  Unix;  invoking  the 
unit  evaluates  the  definitions  in  all  of  the  program’s  units  and  then  executes 
their  intialization  expressions  in  sequence.  Thus,  when  InteractivePhoneBook 
is  invoked,  a  new  phone  book  database  is  created  and  a  phone  book  window 
is  opened  by  Main.  The  return  value  of  the  whole  program  is  the  value  of  the 
last  initialization  expression,  which  is  a  bool  value  in  InteractivePhoneBook 
(assuming  Main’s  expression  is  evaluated  last).^ 

Since  linking  and  invocation  are  separate  phases,  linking  can  connect  mu¬ 
tually  recursive  functions  across  units.  Figure  4  defines  a  slightly  revised 
version  of  the  phone  book  program,  IPB,  where  error  is  part  of  the  Gui  unit. 
Links  flow  both  from  PhoneBook  to  Gui  and  from  Gui  to  PhoneBook.  Thus, 


®  Main  is  not  a  special  name. 

*  Our  informal  graphical  notation  does  not  specify  the  order  of  units  in  a  compound  unit, 
but  a  textual  notation  covers  this  aspect  of  the  language. 
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InteractivePhoneBook 


Fig.  3.  Linking  units  to  define  a  complete  program 


the  insert  function  in  PhoneBook  may  call  error  in  Gui,  which  could  in  turn 
call  PhoneBook’s  insert  again  to  handle  the  error. 

A  compound  unit’s  links  must  satisfy  the  type  requirements  of  the  con¬ 
stituent  units.  For  example,  in  InteractivePhoneBook,  Main  imports  the  type 
db  from  PhoneBook  unit  and  also  the  function  openBook:db—^hoo\  from  Gui. 
The  two  occurrences  of  db  must  refer  to  the  same  type.  A  type  checker  can 
verify  this  by  proving  that  the  two  occurrences  have  the  same  source,  which 
is  the  db  exported  by  PhoneBook  In  contrast.  Figure  5  defines  a  “program” 
Bad  in  which  inconsistent  imports  are  provided  to  Main.  Specifically,  db  and 
openBook:  db— >boo\  refer  to  types  named  db  that  originate  from  different  units. 
The  type  checker  will  correctly  reject  bad  due  to  this  mismatch. 

2.3  Programs  that  Link  and  Invoke  Other  Programs 

The  IPB  unit  has  a  fixed  set  of  constituent  units:  Main,  PhoneBook,  and 
Gui.  But  it  is  often  useful  to  define  the  shape  of  a  compound  unit  without 
immediately  specifying  all  of  its  constituent  units.  For  example,  the  inter¬ 
active  phone  book  can  be  implemented  for  different  graphical  platforms,  e.g.. 
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PhoneBook 


erronstr-^void 


Idb::Q,  new:\/o\d—^db  insert:dbxstrxinfp-^vo\d 
infoiifl  numlnfount—^info  v,  1  I 


Main 


db::Q,  new:yo\d^db  openBook:db—>hoo\ 


let  pb  =  new{)  in  openBook{pb) :hoo\ 


dbiiQ  ins$rt:dbxstrxinfo—^\/o\d 
info:: ft  npmInfo:\nt—>info 


fun  operiBook{pb:db)  =  ••• 
fun  erro7^^s:str)  =  •  •  • 

openBook:  d6— errorrstr— >‘Void 


Fig.  4.  Cycles  in  the  linking  graph  are  allowed 


OtherDatabase 


type  db  = 


db::fl 


PhoneBook 


erronstr-^void 


Idb::ft  new:\/o\d^db  insert: dbxstrx inf o—>\/o\d 
inf^::ft  numinfo: i nt— info _ 


db::fl  insert:dbxstrxinfo-^\fo\d 
T>se  info:: ft  numInfo:\r}t’->info 


fun  openBook{pb:db)  =  ••• 
fun  error(s:str)  =  •  ■  • 


openBook: db—^hoo\  erronstr->void 


Mmn  Mismatch^ 


db::ft  new:\/o\d—>db  openBook:db—^boo\ 


let  pb  =  new{)  in  openBook{pb):hoo\ 


I 


Fig.  5.  Illegal  linking  due  to  a  type  mismatch 
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Macintosh  and  Windows,  by  defining  different  GUI  units.  Every  GUI  unit  will 
have  the  same  set  of  imports  and  exports,  so  the  linking  required  to  produce 
the  complete  interactive  phone  book  is  independent  of  the  specific  GUI  unit. 
In  short,  the  IPB  compound  unit  should  be  abstracted  with  respect  to  its  Gui 
unit. 

Since  units  are  values,  this  form  of  abstraction  can  be  achieved  with  a  func¬ 
tion.  Figure  6  defines  MakelPB,  a  function  that  takes  a  GUI  unit  and  returns 
an  interactive  phone  book  unit.  The  dashed  boxes  for  aGui  and  MakelPB 
indicate  that  the  actual  GUI  and  interactive  phone  book  units  are  not  yet 
determined.  MakelPB  can  be  applied  to  different  GUI  implementations  to 
produce  different  interactive  phone  book  programs. 

The  type  associated  with  MakeIPB’s  argument  is  a  unit  type — a  signature — 
that  contains  all  of  the  information  needed  to  verify  its  linkage  in  MakelPB. 
In  the  graphical  notation,  a  signature  corresponds  to  a  box  with  imports,  ex¬ 
ports,  and  an  initialization  expression  type,  but  no  definitions  or  expressions. 
The  signature  for  aGui  is  defined  by  its  dotted  box,  with  :void  indicating  the 
type  of  the  initialization  expression.  Using  only  this  signature,  the  linking 
specified  in  MakelPB  can  be  completely  verified,  and  the  signature  of  the 
resulting  compound  unit  is  determined. 


fun  MakeIPB{aGui)  = 


PhoneBook 


erronstr— ^void  \ 

IdbiiQ  new:\/o\d—^db  insert:dbxstrxinfo-^\/o\d\ 

nup^nfoimt-^info  V...  | 

~ . . [ . . 

Ma^  ^  ^ . X 

1  insdri:dy^trxinfO‘-^\/o\d 

\  1  infoiin  numInfo:\nt—^info 

db::Q  new:wo\d-^db  openBook:db->hoo\ 

let  pb  =  new{)  in  openBook{pb):hoo\ 

1  1  :void 

\openBook:  db—^i^ool  erronstr^void 

Fig.  6.  Abstracting  a  compound  unit  over  one  of  its  constituent  units 


The  MakelPB  function  is  used  to  create  an  interactive  phone  book,  but 
is  not  intended  to  be  a  function  within  the  interactive  phone  book  program. 
Instead,  MakelPB  is  part  of  a  linking  and  invoking  program  that  is  written 
in  the  same  language  as  the  program  it  links.  Invocation  is  expressed  in 
this  language  by  writing  “invoke”  next  to  a  unit.  For  example.  Starter  in 
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Figure  7  is  a  program  that  uses  invoke  to  run  an  interactive  phone  book  with 
a  Macintosh  GUI. 


Starter 


fun  MakeIPB{aGui)  =  1 

- 1 

S::] 

1 

val  MacintoshGui  = 

dbiiil  insertzdbxstrxinfo-¥vo\<i 
info'.'.Q,  numInfo:mt-¥info 

...:void 

openBooh.  )-bool 

(invoke  MakeIPB{MacintoshGui))iboo\ 

Fig.  7.  A  program  that  links  and  invokes  an  interactive  phone  book 


2.4  Dynamic  Linking 

The  invoke  form  also  works  on  units  that  are  not  complete  programs.  In 
this  case,  the  unit’s  imports  are  satisfied  by  types  and  values  from  the  lexical 
environment  of  the  invoke  expression  in  the  invoking  program.  This  gener¬ 
alized  form  of  invocation  implements  dynamic  linking  for  units.  For  example, 
the  phone  book  program  can  exploit  dynamic  linking  to  support  third-party 
“plug-in”  extensions  that  load  phone  numbers  from  a  foreign  source.  Each 
loader  extension  is  implemented  as  a  unit  that  is  dynamically  linked  with  the 
phone  book  program.  The  core  language  must  provide  a  syntactic  form  that 
retrieves  a  unit  value  from  an  archive,  such  as  the  Internet,  and  checks  that 
the  unit  matches  a  particular  signature.  ®  Then,  a  phone  book  user  can  install 
a  loader  extension  at  run-time. 

Figure  8  defines  a  Gui  unit  that  supports  loader  extensions.  The  function 
addLoader  consumes  a  loader  extension  as  a  unit  and  dynamically  links  it  into 
the  program  using  invoke.  The  extension  unit  imports  types  and  functions 
that  enable  it  to  modify  the  phone  book  database.  These  imports  are  sat¬ 
isfied  in  the  invoke  expression  with  types  and  variables  that  were  originally 
imported  into  Gui,  plus  the  error  function  defined  within  Gui.  The  result  of 
invoking  the  extension  unit  is  the  value  of  the  unit’s  initialization  expression, 

®  Type-checking  in  the  load  expression’s  context  ensures  that  dynamic  hnking  is  type-safe. 
Java’s  dynamic  class  loading  is  broken  because  it  checks  types  in  a  type  environment  that 
may  differ  from  the  environment  where  the  clas  is  used  [19]. 
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which  is  required  (via  signatures)  to  be  a  function  with  the  type  dbxfile-^void. 
This  function  is  then  installed  into  the  interface’s  table  of  loader  functions. 


Gui 


db::fl  inserfcdbxstrxinfo-¥vo\d  infor.fl  numlnfoimt-^info 


7 - 7 

fun  eTTor(s:str) 

fun  regisiei:Loader{forrriattstr,  loadeniib>^jilez:^yo'\d)  =,  •  •  • 
fun  addLmderXfofmttkstry  aLddd^...=./.  / 

aJj^ader . . - — 

[dby^  insert: dbxmx  inf o—^vo'id 


registerLoaderiJormat,  invoke 


- - - j  -  -  y 

info’.iCt  numlnfount-^info  erronstr-^void 


:dbxfile-^\/o\d 


openBook:db—^boo\  erronstr— >void 


Fig.  8.  Dynamic  linking  with  invoke 


3  The  Structure  and  Interpretation  of  Units 

In  this  section  we  develop  a  precise  account  of  the  unit  language  design  in  three 
stages.  We  start  in  Section  3.1  with  units  as  an  extension  of  a  dynamically 
typed  language  to  introduce  the  basic  syntax  and  semantics  for  units.  In 
Section  3.2,  we  enrich  this  language  with  definitions  for  constructed  types 
(like  classes  in  Java  or  datatypes  in  ML).  Finally,  in  Section  3.3  we  consider 
arbitrary  type  definitions  (like  type  equations  in  ML).  For  all  three  sections, 
we  only  consider  those  parts  of  the  core  language  that  are  immediately  relevant 
to  units. 

The  rigorous  description  of  the  unit  language,  including  its  type  structure 
and  semantics,  relies  on  well-known  type  checking  and  rewriting  techniques 
for  Scheme  and  ML  [5,11,25].  In  the  rewriting  model  of  evaluation,  the  set  of 
program  expressions  is  partitioned  into  a  set  of  values  and  a  set  of  non- values. 
Evaluation  is  the  process  of  rewriting  a  non- value  expression  within  a  program 
to  an  equivalent  expression,  repeating  this  process  until  the  whole  program 
is  rewritten  to  a  value.  For  example,  a  simple  unit  expression — represented 
in  the  graphical  language  by  a  box  containing  text  code — is  a  value,  while 
a  compound  unit  expression  is  not.  A  compound  unit  expression  can  be  re¬ 
written  to  an  equivalent  unit  expression  by  merging  the  text  of  the  constituent 
units,  as  demonstrated  in  Figure  9.  Invocation  for  a  unit  is  similar:  an  invoke 
expression  is  rewritten  by  extracting  the  invoked  unit’s  definitions  and  initial¬ 
ization  expression,  and  then  replacing  references  to  imported  variables  with 
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values  supplied  for  the  imports.  Otherwise,  the  standard  rules  for  functions, 
assignments,  and  exceptions  apply. 


PhoneBook 


erronstr-^void 


Numberinfo 


type  info  =  •  •  • 

fun  numInfo{n'.\nt):info  f=  •• 


info'.iQ,  numlnfoimt-^info 


infov.VL  lerronstr-fvoid 


tyi^e  db  =  ••• 

funi  new{):db  =  j  •  • 

fuii  insert{d:db,  keyistr,  vxinfo)  = 


fuii  delete{d:db, 


keyistr)  = 


{stIrTable  :=  mc^eStringHashTable{)):vo\6 


db:^  nevr.vo'id—^db  insert:dbxstrxinfo—^vo\d 
info'.iQ,  numlnfount-^info _ 


PhoneBook _ 

erronstr— >-void 

type  info  =  ■•• 
type  db  =  •  •  • 

fun  numInfo{n:\nt)iinfo  =  ••• 
fun  new{):db  =  •  •  • 
fun  insert{d:db,  keyistr,  viinfo)  =  • 
fun  delete{d:db,  keyistr)  —  ••• 


{strTable  :=  makeStringB:ashTable{))iv6i6 

dbiift  newivo\d->db  insertidbxstrxinfo-^void 
infoiifl  numInfoi\r\t-¥info _ 

Fig.  9.  Graphical  reduction  rule  for  a  compound  unit 


3.1  Dynamically  Typed  Units 

Figure  10  defines  the  syntax  of  UNiTd,  an  extension  of  a  dynamically  typed 
core  language.  The  unspecified  expression  forms  of  the  core  language  are 
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extended  with  three  unit-specific  forms:  a  unit  form  for  creating  units,  a 
compound  form  for  linking  units  into  a  compound  unit,  and  an  invoke  form 
for  invoking  units.  The  core  language  must  provide  two  forms  that  are  used 
in  the  process  of  linking  and  invoking:  an  expression  sequence  form  and 
a  letrec  form  for  lexical  blocks  containing  mututally  recusive  definitions. 


e 


imports 

exports 

definitions 

value-defn 

linkage 

invoke-linkage 

value-invoke-linkage 

value-var-decl 

X 


=  unit  imports  exports  definitions  e 
I  compound  imports  exports 
link  e  linkage  and  e  linkage 
I  invoke  e  with  invoke-linkage 
I  e  ;  e  I  letrec  value-defn  *  in  e 
=  import  value-var-decl  * 

=  export  value-var-decl* 

=  value-defn  * 

=  val  value-var-decl  =  e 

=  with  value-var-decl  *  provides  value-var-decl* 
=  value-invoke-linkage  * 

=  value-var-decl  =  e 

=  X 

=  value  variable 


Fig.  10.  Syntax  of  Unitj,  units  for  a  dynamically  typed  core  language 


The  unit  form  consists  of  a  set  of  import  and  export  declarations  followed 
by  internal  definitions  and  an  initialization  expression.  The  variables  specified 
in  the  imports  section  of  the  unit  are  bound  in  the  definition  and  initialization 
expressions.  All  variables  listed  in  the  exports  section  must  be  defined  within 
the  unit.  In  each  definition,  the  expression  on  the  right-hand  side  of  =  must 
be  a  ?;a/«a6/e  expression  in  the  sense  of  Harper  and  Stone  [11] — i.e.,  evaluating 
the  expression  must  not  incur  any  computational  effects — with  the  restriction 
that  imported  and  defined  variables  are  not  considered  valuable.  ®  The  scope 
of  a  defined  variable  includes  all  of  the  definition  expressions  in  the  unit  as 
well  as  the  initialization  expression. 

A  unit  expression  is  a  first-class  value.  There  are  only  two  operations 
on  this  value:  linking  the  unit  and  invoking  the  unit.  There  is  no  way  to 
“look  inside”  of  a  unit  value  to  extract  any  information  about  its  definitions 
or  initialization  expression.  In  particular,  there  is  no  “dot  notation”  for  ac¬ 
cessing  parts  of  a  unit,  since  a  unit  contains  only  unevaluated  definitions  and 
expressions. 

The  compound  form  links  two  constituent  units  together  into  a  new 


®  This  restriction  simplifies  the  presentation  of  the  formal  semantics,  but  it  can  be  lifted 
for  an  implementation,  as  in  MzScheme,  where  accessing  an  undefined  variable  is  detected 
as  a  run-time  error. 
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unit.  ^  Like  unit,  the  compound  form  starts  with  a  list  of  imported  and 
exported  variables.  The  imported  variables  can  be  supplied  as  imports  to  the 
compound  unit’s  constituents.  The  exported  variables  must  be  a  subset  of 
the  constituents’  exports.  The  constituent  units  are  determined  by  two  sub¬ 
expressions:  one  after  the  link  keyword  and  another  after  the  and  keyword. 
Along  with  each  constituent  unit  expression,  the  variables  that  the  unit  is 
expected  to  import  are  listed  after  the  with  keyword,  and  the  variables  that 
the  unit  is  expected  to  export  are  listed  after  the  provides  keyword. 

Variables  are  linked  within  a  compound  unit  by  name.  Thus,  the  set 
of  variables  listed  after  with  for  the  first  constituent  unit  must  be  a  subset 
of  the  variables  imported  by  the  compound  expression  plus  the  variables 
listed  after  provides  for  the  second  constiuent  unit.  Similarly,  the  variables 
exported  by  the  compound  expression  must  be  a  subset  of  the  combined  set 
of  variables  listed  after  provides  for  each  of  the  constituent  units. 

A  compound  expression  is  not  a  value.  It  evaluates  to  a  unit  value  that 
is  indistinguishable  from  a  unit  created  by  unit  with  the  same  imports  and 
exports.  This  unit’s  initialization  expression  is  the  sequence  of  the  first  con¬ 
stituent  unit’s  initialization  expression  followed  by  the  the  second  constiuent 
unit’s. 

The  invoke  form  consumes  a  unit,  determined  by  a  single  expression,  and 
invokes  it.  If  the  unit  requires  any  imported  values,  they  can  be  provided  in 
the  invoke-linkage  section  of  the  invoke  expression,  which  associates  values 
with  names  for  the  unit’s  imports.  An  invoke  expression  evaluates  to  the 
invoked  unit’s  initialization  expression. 

To  simplify  the  presentation,  UNlTd  does  not  allow  a-renaming  for  a  unit’s 
imported  and  exported  variables.  In  MzScheme’s  implementation  of  units, 
imported  and  exported  variables  have  separate  internal  and  external  names, 
so  all  bound  variables  within  a  unit  can  be  a-renamed.  Also,  MzScheme’s 
compound  form  links  imports  and  exports  via  source  and  destination  name 
pairs,  rather  than  requiring  the  same  name  at  both  ends  of  a  linkage. 


3.1.1  UNiTd  Context-sensitive  Checking 

The  rules  in  Figure  11  enforce  the  context-sensitive  properties  that  were  in¬ 
formally  described  in  the  previous  section.  The  checks  ensure  that  a  variable 
is  not  multiply  defined,  imported,  or  exported,  and  that  the  link  clause  of  a 
compound  expression  is  locally  consistent. 


^  Linking  an  arbitrary  number  of  units  together  in  a  single  compound  expression  (as  in 
MzScheme’s  implementation)  is  a  simple  generalization. 


11 


'S  distinct  The,,  The 
r  hinvoke  with  a:  =  e 


xJU^  distinct  XgQ  x 

r,S’,®7l-e’  r,x’,Xif-e6 

r  hunit  import  ^  export  ^ 
val  X  =  e  in 


SiU»]^i1Ja:p2  distinct  Xg  distinct 
^^CxjU^  x^Cx^x^  W^C^Ux^  rhei  T  1-62 

r  [-compound  import  ^  export  x^ 

link  ei  with  provides 

and  62  with  provides  x^ 

The  notation  x  indicates  either  a  set  or  sequence  of  variables  x,  depending  on  the  context.  The  notation 
val  X  =  e  indicates  the  sequence  val  x  =  e  where  each  x  is  taken  from  the  set  x  with  a  corresponding 
e  from  the  set  e. 


Fig.  11.  Checking  the  form  of  UniTj  expressions 


invoke  (unit  import  Xi  export  Xg  if  Xj  C  x^ 
val  a;  =  6  in  eft) 
with  Xy,  =  v^u) 

[t;u,/a:,„](letrec  val  x  =  e  in  eft) 

compound  import  xj  export  xj 

link  (unit  import  xiT  export  x^T 

val  xi  =  ei  in  efti)  with  provides  x^ 
and  (unit  import  xiJ  export  xiJ 

val  a;2  =  62  in  eft2)  with  x^  provides  x^ 


unit  import  xj 
export  xi" 
val  xi  =  ei 
val  X2  =  62 
in  Cf)i  ,  6^2 

if  xTUxJUxi  distinct,  xiT  C 's^,  x^  C  x^,  xiJ  Q  x^,  and  x^  C 

Fig.  12.  Reducing  IJNlTd  expressions 
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3.1.2  UNlTd  Evaluation 

The  unit-specific  reduction  rules  for  UNlTd  are  defined  in  Figure  12.  These 
rules  are  a  modification  of  those  for  Scheme  [5].  The  first  rule  shows  that  an 
invoke  expression  reduces  to  a  letrec  expression  containing  the  invoked  unit’s 
definitions  and  initialization  expression.  In  this  letrec  expression,  imported 
variables  are  replaced  with  values  supplied  for  the  imports.  The  variables 
supplied  by  invoke’s  with  clause  must  cover  all  of  the  imports  required  by 
the  unit. 

The  second  rule  defines  how  the  compound  expression  combines  two 
units:  the  definitions  from  each  unit  are  merged  and  the  initialization  ex¬ 
pressions  are  sequenced.  The  compound  rule  requires  that  the  constituent 
units  provide  at  least  the  expected  exports  (according  to  the  provides  clauses) 
and  need  no  more  than  the  expected  imports  (according  to  the  with  clauses). 
The  reduction  rule  also  requires  that  unexported  definitions  in  the  two  units 
have  been  appropriately  o-renamed  to  avoid  collisions  when  the  definitions 
are  merged. 

3.2  Units  with  Constructed  Types 

Figure  13  extends  the  language  in  Figure  10  for  a  statically  typed  language 
with  programmer-defined  constructed  types,  such  as  ML  datatypes.  In  the 
new  language,  UniTc,  the  imports  and  exports  of  a  unit  expression  include 
type  variables  as  well  as  value  variables.  All  type  variables  have  a  kind  ®  and 
all  value  variables  have  a  type.  The  compound  and  invoke  expressions  are 
extended  in  the  natural  way  to  handle  imported  and  exported  types. 

The  definition  section  of  a  unit  expression  contains  both  type  and  value 
definitions.  Type  definitions  of  the  form  type  t  =  x\  t\  \  Xr  >  Xs  are  similar 
to  ML  datatype  definitions.  For  simplicity,  every  type  defined  in  UniTc  has 
exactly  two  variants.  Instances  of  the  first  variant  are  constructed  with  the 
x\  function,  which  takes  a  value  of  type  t\  and  constructs  a  value  of  type  t. 
Instances  of  the  second  variant  are  constructed  with  Xt  given  a  value  of  type 
Tf.  The  Xs  function  is  the  standard  selector  function  for  a  datatype. 

The  type  of  a  unit  expression  is  a  signature  of  the  form  sig  imports  exports 
T  end  where  imports  specifies  the  kinds  and  types  of  a  unit’s  imports  and 
exports  describes  the  kinds  and  types  of  its  exports.  As  in  unit,  types  in  either 
imports  or  exports  can  be  used  in  the  type  expressions  within  the  signature. 
The  type  expression  r  is  the  type  of  the  unit’s  initialization  expression,  which 
cannot  depend  on  type  variables  listed  in  exports. 

The  type  checking  and  evaluation  rules  for  UniTc  are  natural  extensions 


®  The  only  kind  in  this  language  is  H,  which  is  the  kind  of  types  for  values.  We  declare  ex¬ 
plicit  kinds  in  anticipation  of  future  work  that  handles  type  constructors  and  polymorphism, 
which  require  kinds  such  as  ft— 
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imports 

import  type-var-decl*  value-var-decl* 

exports 

= 

export  type-var-decl*  value-var-decl* 

definitions 

= 

datatype-defn  *  value-defn  * 

datatype-defn 

= 

type  t  —  xr\xT>x 

linkage 

= 

with  type-var-decl*  value-var-decl* 
provides  type-var-decl*  value-var-decl* 

invoke-linkage 

= 

type-invoke-linkage  *  value-invoke-linkage  * 

type-invoke-linkage 

= 

type-var-decl  =  r 

type-var-decl 

= 

t  ::  n 

value-var-decl 

X  :  T 

r,  a 

t  \  r  T  \  signature 

signature 

= 

sig  imports  exports  r  end 

t 

type  variable 

K 

= 

type  kind 

1.  Syntax  extensions  for  UniTc,  units  for  a  core  language  with  constructed 

types 


to  those  of  UNiTd.  The  interested  reader  is  referred  to  Appendix  A  for  details. 
3.3  Units  with  Type  Equations 

UniTc  is  sufficient  to  extend  languages  where  a  new  constructor  is  associ¬ 
ated  with  every  defined  type.  Other  languages  support  type  equations  of  the 
form  type  t  =  r,  which  defines  t  as  an  abbreviation  for  the  type  r.  If  the 
complete  program  is  known,  the  variable  t  can  be  replaced  everywhere  with 
r.  Otherwise,  the  expansion  of  t  must  be  delayed  until  the  program  is  fully 
assembled. 

UNiTe  extends  UniTc  with  type  equations.  Since  two  units  can  contain 
mutually-recursive  definitions,  naively  linking  two  units  with  type  equations 
may  result  in  a  cyclic  type  definition.  To  prevent  cyclic  definitions  created  by 
linking,  signatures  in  UNiTe  include  information  about  type  dependencies. 


definitions 

type-defn 

signature 

dependency 


type-defn  *  datatype-defn  *  value-defn  * 
type  t  ::  K  =  a 

sig  imports  exports  depends  dependency  *  t  end 
t  t 


Fig.  14.  Syntax  extensions  for  UNiTe,  units  for  a  language  with  type  definitions 


Figure  14  defines  syntax  extensions  for  UNiTe,  including  a  new  signature 
form  that  contains  a  depends  clause.  The  dependency  declaration  tg 
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ti  means  that  an  exported  type  depends  on  an  imported  type  U.  When 
two  units  are  linked  with  a  compound  expression,  the  unit  system  traces 
the  set  of  dependencies  to  ensure  that  linking  does  not  create  a  cyclic  type 
definition.  The  signature  for  a  compound  expression  propagates  dependency 
information  for  types  imported  into  and  exported  from  the  compound  unit. 

The  type  checking  and  evaluation  rules  for  UNlTg  are  natural  extensions 
to  those  of  UniTc.  The  interested  reader  is  referred  to  Appendix  B  for  details. 

4  Implementation 

Closed  units  can  be  compiled  separately  in  the  same  way  as  closed  functors 
in  ML.  When  compiling  a  unit,  imported  types  are  obviously  not  yet  deter¬ 
mined  and  thus  have  unknown  representations.  Hence,  expressions  involving 
imported  types  must  be  compiled  like  polymorphic  functions  in  ML  [22,14]. 
Otherwise,  the  restrictions  implied  by  a  unit’s  interface  allow  inter-procedural 
optimizations  within  the  unit  (such  as  inlining,  specialization,  and  dead-code 
elimination).  Furthermore,  since  a  compound  unit  is  equivalent  to  a  simple 
unit  that  merges  its  constituent  units,  intra-unit  optimization  techniques  nat¬ 
urally  extend  to  inter-unit  optimizations  when  a  compound  expression  has 
known  constituent  units. 

In  MzScheme’s  implementation  of  UNlTd,  units  are  compiled  by  trans¬ 
forming  them  into  procedures.  The  unit’s  imported  and  exported  variables 
are  implemented  as  first-class  reference  cells  that  are  externally  created  and 
passed  to  the  procedure  when  the  unit  is  invoked.  The  procedure  is  responsi¬ 
ble  for  filling  the  export  cells  with  exported  values  and  for  remembering  the 
import  cells  for  accessing  imports  later.  The  return  value  of  the  procedure  is  a 
closure  that  evaluates  the  unit’s  initialization  expression.  Figure  15  illustrates 
this  transformation  on  an  atomic  unit.  A  compound  unit  encapsulates  a  list  of 
constituent  units  (instead  of  definitions)  and  a  procedure  that  propagates  im¬ 
port  and  export  cells  to  the  constituent  units,  creating  new  cells  to  implement 
variables  in  the  constituents  that  are  not  exposed  by  the  compound  unit. 

5  Related  Module  Languages 

Our  unit  language  incorporates  ideas  that  have  evolved  in  distinct  language 
communities: 

•  Traditional  languages  like  C  have  relied  on  the  filesystem  as  the  language  of 
modules.  Programs  (makefiles)  manipulate  “.o”  files  to  select  the  modules 
that  are  linked  into  a  program,  and  module  files  are  partially  linked  to  create 
new  “.o”  or  library  files.  Modern  linking  systems  such  as  ELF  [21]  support 
dynamic  linking.  However,  even  the  most  advanced  linking  systems  rely  on 
a  global  namespace  of  function  names  and  module  (Le.,  file)  names,  so  that 
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(unit  (import  even)  (export  odd) 

(define  odd  (lambda  (x) 

(if  (zero?  x) 

#f 

(even  (subl  x))))) 

(odd  13)) 

=> 

(lambda  (even-cell  odd-cell) 

(set-cell!  odd-cell 
(lambda  (x) 

(if  (zero?  x) 

#f 

((cell-value  even-cell)  (subl  x))))) 

(lambda  ()  ((cell-value  odd-cell)  13))) 

Fig.  15.  An  example  of  the  basic  compilation  strategy  for  Scheme  units 


modules  can  only  be  linked  and  invoked  once  in  a  program. 

•  Languages  such  as  Ada  [1],  Modula-2  [24],  Modula-3  [9],  Haskell  [12],  Com¬ 
mon  Lisp  [20],  and  Java  [8]  have  established  the  “packages”  approach  to 
modularity,  in  which  type  and  value  definitions  are  grouped  into  packages 
that  explicitly  import  parts  of  other  packages.  The  package  system  delin¬ 
eates  the  boundaries  of  each  module  and  forces  the  specification  of  static 
dependencies  between  modules.  Linking  and  invocation  are  clearly  sepa¬ 
rated,  which  allows  mutually  recursive  function  definitions  across  package 
boundaries. 

The  main  weakness  of  a  package  system  is  its  reliance  on  a  global  names¬ 
pace  of  packages  with  importing  connections  hardwired  into  each  package. 
In  contrast  to  our  unit  language,  package  systems  do  not  permit  the  reuse 
of  a  single  package  for  multiple  invocations  in  a  program  or  the  external 
selection  of  connections  between  packages.  ®  There  is  also  no  way  to  merge 
several  packages  into  a  new  package  that  hides  parts  of  the  constituent 
packages.  These  shortcomings  make  packages  less  reuseable  than  units. 

Among  the  languages  with  packages,  only  Java  provides  a  mechanism 
for  dynamic  linking.  This  mechanism  is  similar  to  the  dynamic  linking  for 
units,  but  it  is  expressed  indirectly  via  the  language  of  class  loaders,  and  is 
not  fully  general  due  to  the  constraints  of  a  global  package  namespace. 

•  ML’s  functor  system  [17]  is  the  most  notable  example  of  a  language  that 
lets  a  programmer  describe  abstractions  over  modules  and  gives  a  program¬ 
mer  direct  control  over  assembling  modules.  Programmers  can  create  mod¬ 
ules  that  are  completely  private  to  other  modules  by  instantiating  functors 

®  Modula-3’s  generics  allows  the  former  but  not  the  latter. 
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anonymously  as  arguments  to  other  functors.  The  ML  community  has  pro¬ 
duced  a  large  body  of  work  exploring  variations  on  the  basic  module  system, 
especially  variaions  for  higher-order  modules  [2,10,15,16,18,23]. 

Unfortunately,  the  standard  mechanism  for  combining  modules  relies  pre¬ 
vents  the  definition  of  mutually  recursive  types  or  procedures  across  module 
boundaries.  And  unlike  units,  ML  provides  no  mechanism  for  dynamic  link¬ 
ing  since  the  module  language  is  distinct  from  the  evaluation  language  with 
a  strict  phase  separation.  Duggan  and  Sourelis  have  investigated  “mixins” 
as  a  solution  to  the  recursion  problem  [4].  Their  approach  is  radically  dif¬ 
ferent  from  ours  and  does  not  address  the  problems  of  higher-order  modules 
or  dynamic  linking. 

In  addition,  Cardelli  [3]  anticipated  the  unit  language’s  emphasis  on  module 
linking  as  well  as  module  definition.  Our  unit  model  is  more  concrete  than 
his  proposal  and  addresses  many  of  his  suggestions  for  future  work.  Kelsey’s 
proposed  module  system  for  Scheme  [13]  captures  most  of  the  organizational 
properties  of  units,  but  does  not  address  static  typing  or  dynamic  linking.  In 
short,  our  unit  model  fuses  the  best  parts  of  existing  module  systems  in  a 
novel,  compact  way  that  is  applicable  to  many  core  languages. 

6  Conclusion 

Encapsulating  program  fragments  is  only  half  the  story  for  modular  program¬ 
ming.  The  other  half  is  linking  and  invoking  these  encapsulations,  sometimes 
in  the  context  of  a  program  that  is  already  executing.  A  promising  approach 
to  giving  programmers  control  over  the  latter  half  is  to  integrate  program  frag¬ 
ments  into  the  core  programming  langauge.  We  have  shown  how  this  can  be 
accomplished  with  program  units  to  give  the  programmer  a  flexible  language 
for  combining  programs  fragments  without  sacrificing  the  distinct  phases  of 
linking  and  evluation. 

The  unit  language  was  originally  implemented  to  simplify  the  development 
of  DrScheme  [6],  Rice’s  Scheme  programming  environment.  Units  simplify 
DrScheme’s  implementation  as  a  large  and  dynamic  program.  DrScheme  sup)- 
ports  multiple  language  dialects  and  third-party  extensions  that  hook  into  its 
complex  graphical  interface.  DrScheme  also  acts  as  a  kind  of  operating  sys¬ 
tem  for  client  programs  that  are  being  developed,  launching  client  programs  by 
dynamically  linking  them  into  the  system  while  maintaing  the  boundaries  be¬ 
tween  clients.  Units  express  DrScheme’s  extensibility  and  OS-nature  directly 
and  elegantly. 

Our  proposal  does  not  necessitate  a  tight  integration  of  units  into  the  core 
language.  A  weaker  form  of  integration — using  a  separate  language  for  defining 
and  linking  units — can  acheive  similar  benefits  if  essential  design  features  are 
kept  intact:  compound  units,  a  mechanism  to  inject  units  into  the  set  of  run- 
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time  values,  and  an  core  expression  for  invoking  units.  In  future  work,  we 
intend  to  explore  linking  languages  that  are  separate  from  the  core  language 
to  determine  the  optimal  level  of  integration. 
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Appendix 

A  UniTc  Type  Checking  and  Evaluation 

For  economy,  we  introduce  the  following  unusual  abbreviation,  which  summa¬ 
rizes  the  content  of  a  signature  with  the  indices  used  on  names: 


sig[i,  e,  b]  =  sig  import  tjU/Cj  Xf-Ti 
export  tey.Ke  X^XTe 
n 


To  allow  the  use  of  specialized  units  in  place  of  more  general  units,  sig¬ 
natures  have  a  subtype  relation  (see  Figure  A.l):  a  specific  signature  ts  is  a 
subtype  of  a  more  general  signature  tg  if  1)  ts  has  fewer  imports  and  more 
exports,  2)  the  type  of  each  imported  name  in  ts  is  a  subtype  of  the  one  in  tg, 
3)  the  type  of  each  exported  name  in  tg  is  a  subtype  of  the  one  in  ts,  and  4) 
the  type  of  the  body  expression  in  ts  is  a  subtype  of  the  body  expression  type 
intg. 


VXiltTjl  G  Xil'.Tii,  3XiliTi2  G  Xi2iTi2  S.t.  Ti2  <  Tj! 

'^Xe2’’Te2  G  Xe2XTe2,^Xe2’’Tel  €  XelXT^  S.t.  Tel  <  Te2  T  he  :  t'  t'  <  T 

sig[il,el,bl]  <  sig[«;2,  e2,  b2]  F  hje  :  r 


Fig.  A.l.  Subtyping  and  subsumption  in  UniTc  signatures 


The  typing  rules  for  UniTc  are  shown  in  Figure  A.2.  These  rules  are  typed 
extensions  of  the  rules  from  Section  3.1.1.  The  special  rule  hj  is  used  when 
subsumption  is  allowed  on  an  expression’s  type.  Subsumption  is  used  carefully 
so  that  type  checking  is  deterministic.  For  example,  full  subsumption  is  not 
allowed  in  the  expression  Cu  for  the  invoke  rule  because  the  initialization 
expression  type  in  e^’s  signature  supplies  the  type  of  the  entire  invoke 
expression. 

The  reduction  rules  for  UniTc  in  Figure  A.3  resemble  the  reductions  in  Sec¬ 
tion  3.1.2.  The  only  difference  for  UniTc  is  that  the  invoke  and  compound 
reductions  propagate  type  definitions  as  well  as  val  definitions. 
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r'  =  r,  ti'.lKi,  teiiKe  FTV {Tb)  H  te  =  0 
r'  \rTi  ::  Ki  F'  Ftp  ::  F'  hr/,  ::  12 

r  l-sig[i,  e,b]  ::  Q 


tUx  distinct  F'  hr^  ::  F  ha  ::  k 

F  hs^  :  T  F  heu  :  sig[i,  e,  &] 

sig[i,  e,  6]  <  sig  import  t::K  xir  export  Tb 

F  hinvoke  with  t::K  =  a  x:t  =  e  :  Tb 


tiUtUxiUxrUxTU^iUx’  distinct  C  t::fiUs;TUa;i:T|Ux7jT7U®s5'rs 

F  hsig[i,  e,  6]  ::  F'  =  F,  tliH  F'  hri  ::  U  T'  hr?  ::  T'  hy  ::  Q 

T"  =T' ,xjrri,x\yTr^fl,  XfiTr  ->•  t,Xs:t  (ti  a)  ->•  (xr  ->  a)  ^  a 

_ hsc  :  r  F''  he6  :  Tb _ 

F  hunit  import  ti'.iKi  Xi'.Ti  export  x^’t^ 

type  t  =  x\  T\\  Xx  T,  >  Xs 
val  x:t  =  e  in  Cb 
:  sig[i,  e,  b] 


tjUtpiUtp2UiiUx^rUa:p2  distinct  tgUare  distinct 
txviy-KyjlliXwi'.Tyjl  C  ti:iKiUtp2::Kp2liXi:Ti\JXp2:Tp2 

^iy2 •  *^1172  ^  ••tZpi LJ2/ j •T /LJXpi •'^pX 

C  tp\ ••ACp3[LJ^p2**^p2^^pl 

F  hsig[*,  e,  6;2]  ::  F  hsig[«;i,pi ,  67]  ::  F  hsig[«;2,p^,  6^]  :: 

F  hei  :  sig[i7 ,  ei ,  67 ]  F  he2  :  sig[i^,  e2, 6;?] 
sig[i7,  e7, 67]  <  sig[«;7,p7, 67]  sig[ig,  e2,  b2]  <  sig[w2,p2,  b2] 

F  hcompound  import  ti'.iKi  XiiTi  export  te’.iKe  Xe’-Tg 

link  ei  with  Xy,i:Ty,i  provides  tpi::Kpi  XpiiTpi 

and  62  with  <u,2“«u)2  provides  tp2’>Kp2  Xp2iTp2 

:  sig[i,  e,  62] 


Fig.  A.2.  Type  checking  for  UniTc 


B  UNiTe  Type  Checking  and  Evaluation 


The  following  abbreviation  expresses  a  UNiTe  signature: 

sig[i,  e,  di,  de,  b]  =  sig  import  ti'.iKi  xiiTi 

export  t 

depends  t^e  tdi 

n 
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invoke  (unit  import  tiiiKi  Xi’.Ti  export  tgiiKe  x^ife 
type  t  =  x\  T\  \  Xx  Tf  >  Xs 
val  x:t  =  e  in  Cb) 

Vnth  tyjttK-nJ  —  ^y)  XyjtXyj  —  VyJ 

<->  Vtu/a:w](letrec  type  t  =  x\  t\  \  Xr  t,  >  Xs 

val  x:t  =  e  in  eb) 


compound  import  tiiiKi  xf.Ti  export  teUKg 

link  (unit  import  tutiKu  xniTii  export  tei“«ei  Xei:Tei 
type  h  =  X|1  T|1  I  Xrl  Tri  >  Xsl 
val  xi:ti  =  ei 
in  661 ) 

"With  Xyj\lXyjl 

provides  tpi'.iKpi  XpiiTpi 

and  (unit  import  Xt2!7‘i2  export  <e2”«e2  Xe2:Te2 

type  t2=  X\2  T|2  I  Xr2  'rr2  >  Xs2 
"vsj  X2:T2  =  62 
in  662) 

"With  tyj^*lKyj2  ^■w2*'^vj2 

provides  tp2’.’Kp2  Xp2'Tp2 

«->  unit  import  tinni  XiXTi 
export  te'.'.Ke  Xe’Xe 
type  ti  =  X|1  T|1  I  Xrl  Trl  >  Xsl 
type  <2  =  2^12  X\2  1  Xr2  Tx2  >  Xs2 
val  X\XTi  =  6i 
val  X2’T2  =  62 
in  661  ;  662 

if  fiUi2U?iUxrUx2Ux7  distinct 

Fig.  A.3.  Reduction  rules  for  UniTc 


The  subtyping  rule  in  Figure  B.l  accounts  for  the  new  dependency  declarations 
by  requiring  that  a  specific  signature  declares  more  dependencies  than  a  more 
general  signature. 

The  type  checking  rules  for  UNiTg  are  defined  in  Figure  B.2.  To  calculate 
type  equation  dependencies  for  the  signature  of  a  simple  unit,  the  type  check¬ 
ing  rules  rely  on  the  oc £>  relation,  which  associates  a  type  expression  with  each 
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Tfel  <  Tb2  _ _ 

til^iKii  C  ti2''Ki2  D  fe2-i«e2 

idel  ^  tde2  ^di2 

VariiSTji  G  xhith,  3xii:Ti2  G  Xi^'.Tii  s.t.  Ti2  <  Ta 

'iXf_2'Te.2  €  X^^7^,^Xe2'Tel  €  Xel'.t^  S.t.  T el  <  T e2 

sig[il ,  el ,  dil ,  del ,  bl]  <  sig[*,?,  e2,  di2,  de2,  b2] 

Fig.  B.l.  Subtyping  and  subsumption  in  UNiTe  signatures 


of  the  type  variables  it  references  from  the  set  of  type  equations  D: 

T  ccd  t  iff  i  G  FTV{t) 

or  {3{t'  =  t')  eD  s.t.  t'  G  FTV{t)  and  r'  ocd  t) 

FTV{t)  denotes  the  set  of  type  variables  in  r  that  are  not  bound  by  the 
import  or  export  clause  of  a  sig  type.  Types  in  a  set  of  type  equations  D 
can  be  eliminated  from  a  type  expression  with  the  {•Id  operator,  as  follows: 

ft  if  T=t  and  t^D 

if  T=t  and  {t  =  r')  Gi? 

\r'\D-^\r"\iy  _ _  if  r=T'^T" 

\t\j^  =  J  sig  import  Uv.Ki  Xi'.\Ti\j),  if  r=sig[i,  e,  di,  de,  b] 

export  tei:K,e  Xe'\Te\Ty  ^  ^ 

,  j  7 - j—  and  t  f  tiUte) 

depends  tde  tdi 

'  kfrlo' 


and  similarly  expanded  in  a  value  expression,  sketched  as  follows: 


import  ti'.iKi  Xi’.Ti 
export  te’-K-e  Xe'.Te 

type  tgV.Ka  —  |ra|j,, _ 

type  t  =  Xj  jrilj,,  |  Xr  \rr\p,  >  x, 
val  x:\T\jy,  =  \e\jy,  in 


if  e=x 

if  e=unit 

import  ti'.iKi  Xi’.Ti 

export  te’.’.Ke  Xe’.Te 

type  ta’.’.Kg  =  Tg _ 

type  t  =  x\  T]  \  X,  Tf  >  Xs 
val  x’.T  =  ein  Cf, 
and  D'  =  {(t  = 

and  t  ^  tiUtelita}Jt} 


The  subscript  D  is  left  off  of  |  •  [  when  D  is  clear  from  context. 

The  UNiTe  reductions  in  Figure  B.3  differ  only  slightly  from  the  UniTc 
reductions.  Type  abbreviations  are  immediately  expanded  away  in  the  invoke 
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r'  =  r,  UliKi,  te’-iKe  FTV{Tb)  nte  =  9 

V  \-Ti  ::  Ki_r'  tie  Jl,«e  J"'  :: 

_ ide  —  ^6  ^di  —  _ 

r  l-sig[i,  e,  di,  de,  6]  ::  ft 

i^U7UxiUsiUx;U^^  distinct  C  t„::KaUt;:J^UxTrUxiTTiU®7l7vU®^ 

D  =  {ta  =  T(j)  Tfl  0C£)  T(,  9^£)  to  for  {ta  —  Ta)^  {tg,  Tg,)  G  D 

tde  tdi  =  {*a  U  I  {ta  =  Tg)  ^  D  and  U  Eti  and  tgEtl  and  Tg  ocd  ti} 
r  l-sig[i,  e,  di,  de,  6]  ::  f2  T' =  T,ti::Ki,t::Q  ro  =  r',  Hto  ::  «o 

r  hlnl  ::  r'  I-|t;|  ::  Q  T'  \-\t\  ::  il 

T"  =r',Xi:|Til,X|:|ril  -¥  |t|,a;r:|Tr|  ->•  \t\,Xs:t  -)•  (|ril  ->•  a)  ^  (|rr|  ->  a)  ->  a 

_ r^h-sl^hlrl  r'h\eb\:n _ 

r  hunit  import  tiiiKi  x^fl 
export  te'.lKe  XglTe 

type  tg'.lKg  =  Tg 

type  t  =  X\  T\\  X,  Tr  >  Xs 
val  x:t  =  e  in  ej 
:  sig[i,  e,  di,  de,  6] 

TilJt^Ut^U^lix^iUx^  distinct  distinct 

iw2**^w2^^w2*'^'w2  ^  Utpl !"KplLJirj*TiLJ2rpi •Tpl 

te':KeUXe:Te  Q  tpi::Kpi\Jtp2:iKp2(JXpi'.Tpi[JXp2iTp2 

r  l-sig[i,  e,  di,  de,  b2]  ::  17 

Thsig[wl,pl,dil,del,bl]  ::  17  T  \-s\g[w2,p2,di2,de2,b2]  ::  17 
r  hei  :  sig[i7 ,  e7,  dii,  del,  61]  T  l-e2  :  sig[i;2,  e2,  di2,  de2,  b2] 
sig[il ,  el ,  dil ,  del ,  61  ]  <  sigfiol ,  pi ,  dil ,  del ,  bl  ] 
s\g[i2,  e2,  di2,  de2,  b2]  <  s\g[w2,p2,  di2,  de2,  b2] 

{tdili  trfel)  (tde2)  ^di2)  ~  0 

tde  tdi  =  {tg'^  ti  \  ti  eti  and  tgEtl  and  tg-^  UE  tjel  tdi\^tde2  tdi2} 

r  hcompound  import  ti'.’.Ki  xf.Ti  export  tgi’-Ke  x^rZ 

link  ei  with  twi’^Kwi  xZAytZZi  provides  tpi;:«pi  XpitTpi 
and  e2  with  lu,2"«ui2  Xyj2'Tw2  provides  7p2::Kp2  Xp2’Tp2 
:  sig[i,  e,  di,  de,  b2] 

Fig.  B.2.  Type  checking  for  UNlTg 

reduction,  and  the  compound  reduction  preserves  and  merges  type  equations 
when  linking. 
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invoke  (unit  import  tiiiKi  Xi’.Ti  export  tgiiKe  Xe’Te 
type  iottKo  =  Ta 
type  t  =■  x\  T\\  Xt  Tf  >  Xs 
val  x:t  =  e  in  ej,) 

"With  ty)ltKfju  —  Xyji'Tyj  —  Vy) 

■->  [Tyj/(Tju,  i;u,/a;^](letrec  type  t  =  x\  |ti|  |  x^  |rr|  >  Xs 

veil  a::|r|  =  |e|  in  |e6|) 

where  D  =  {ta  =  Ta) 

compound  import  ti'.iKi  Xiiri  export  te”«e  Xe'Te 

link  (unit  import  xu'.th  export  tei”«ei  Xei:Tei 

type 

type  h  =  X\i  T|1  I  Xrl  Trl  >  Xsl 

val  x\iT\  =  e\  in  eti) 

"With  ty)\ZlKyj\  XyjllTyjl 

provides  tpiziKpi  Xpi’.Tpi 

and  (unit  import  Xi2ZTii  export  J^zzk^  Xe2-Tei 

type  ta2ZZKa2  =  Ta2 _ 

type  t2  =  X\2  T|2  I  Xt2  Tr2>  *52 
val  X2ZT2  =  62  in  662) 

WUtll  tyj2**^yj2  Xyj2*'^w2 

provides  tp2ZZKp2  Xp2ZTp2 

^  unit  import  tizzni  x^ztI 
export  teZZKg  XgZTe 
type  talZZKal  =  Tal 

type  ta2ZZKa2  =  To2 _ 

type  h  =  X\i  T|1  I  Xrl  Trl  >  a^si 
type  <2  =  Xi2  T|2  1  Xr2  r,2  >  3^52 
val  xiZTi  =  ei 
val  X2'T2  =  62 
in  ebi  ;  652 

if  distinct 

Fig.  B.3.  Reduction  rules  for  UNiTe 
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Abstract 

Much  recent  work  on  the  compilation  of  statically  typed  languages  such  as  ML  re¬ 
lies  on  the  propagation  of  type  information  from  source  to  object  code  in  order  to 
increase  the  reliability  and  maintainabilty  of  the  compiler  itself  and  to  improve  the 
eflSciency  and  verifiability  of  generated  code.  To  achieve  this  the  program  transfor¬ 
mations  performed  by  a  compiler  must  be  cast  as  type-preserving  translations  be¬ 
tween  typed  intermediate  languages.  In  earlier  work  with  Minamide  we  studied  one 
important  compiler  transformation,  closure  conversion,  for  the  case  of  pure  simply- 
typed  and  polymorphic  A-calculus.  Here  we  extend  the  treatment  of  simply-typed 
closure  conversion  to  account  for  recursively-defined  functions  such  as  are  found  in 
ML.  We  consider  three  main  approaches,  one  based  on  a  recursive  code  construct, 
one  based  on  a  self-referential  data  structure,  and  one  based  on  recursive  types.  We 
discuss  their  relative  advantages  and  disadvantages,  and  sketch  correctness  proofs 
for  these  transformations  based  on  the  method  of  logical  relations. 
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1  Introduction 


Closure  conversion  is  a  critical  program  transformation  for  higher-order  lan¬ 
guages  that  eliminates  lexically  nested,  first-class  functions  or  procedures.  In 
particular,  closure  conversion  translates  each  function  definition  /  into  a  cu— 
— e  -  a  data  structure  consisting  of  a  pointer  to  closed  c-de  and  another  data 
structure  which  represents  the  e—i — ve—  or  context  of  the  function.  The 
code  abstracts  the  arguments  of  /  as  well  as  the  free  variables  of  /,  and  the 
environment  provides  the  values  for  the  free  variables  of  /.  Function  appli¬ 
cation  is  translated  to  a  sequence  which  invokes  the  code  of  the  function’s 
closure  on  the  environment  of  the  closure  and  the  arguments.  Since  the  code 
is  closed  and  separated  from  the  data  which  it  manipulates,  it  may  be  defined 
at  the  top-level  and  shared  by  all  closures  that  are  instances  of  the  function. 
In  this  respect,  closure  conversion  reifies  meta-level  constructs  (i.e.,  closures 
and  environments)  as  object-level  constructs  (i.e.,  code  and  tuples)  in  the 
same  fashion  that  conversion  into  continuation-passing  style  reifies  meta-level 
continuations  as  object-level  functions. 

As  an  example,  the  source  level  expression 


let  / 

=  \x.Xy.\z.x  -\-y  z 

f 

=  /3 

f" 

=  /'4 

in 

f'5 

end 


might  be  closure-converted  to  the  target  language  expression 

let  Zcode  =  A[e,  z].{7T2  e)  +  (tti  e)  +  z 

2/code  ~  A[e,  2/].{2code)  {Vj  '^1  )) 

Xcode  ~  A[e,  a?].(2/code5  (^)) 


/  —  (^codej  0) 

f  =  (tti  /)  [7r2  /,  3] 

r  =(7ri/')[^2/',4] 


in 


(tti  /")  [tts  f",  5] 

end 
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The  function  /  becomes  a  pair  of  the  code  Xcode  and  an  empty  environment. 
The  definition  of  f  invokes  /  by  calling  the  code  of  /  (a;code)5  passing  to  it  its 
environment  and  the  argument  3.  The  code  builds  a  new  closure,  containing 
the  code  Vcode  and  the  environment  consisting  of  the  value  bound  to  x  {i.e.,  3). 
Hence,  f  becomes  bound  to  the  value  (ycodej  (3)).  The  definition  of  f"  invokes 
f  by  calling  the  code  ^codej  passing  to  it  its  environment  and  the  argument  4. 
The  code  builds  a  new  closure,  containing  the  code  Zcode  and  the  environment 
consisting  of  the  values  of  y  (i.e.,  4)  and  x  {i.e.,  3).  Note  that  the  value  of 
X  is  obtained  from  the  environment  e.  Hence,  f"  becomes  bound  to  the  value 
(^codej  (4,3)).  The  body  of  the  let  invokes  this  closure  on  the  argument  5. 
Hence,  within  the  definition  of  .^code,  e  is  bound  to  (4, 3)  and  z  is  bound  to  5. 
The  body  of  this  code  computes  the  value  3  +  4  +  5  =  12. 

In  earlier  work  with  Minamide  [6]  we  considered  the  question  of  how  to 
perform  closure  conversion  in  a  typed  setting.  We  sought  to  relate  the  type 
of  a  program  after  closure  conversion  to  its  type  prior  to  closure  conversion. 
The  key  observation  is  that  the  naive  approach  to  closure  conversion  sketched 
above  does  not,  in  general,  yield  a  well-typed  term.  For  instance,  consider  the 
following  source  expression: 

if  c  then  Aa;:int.a:  +  a  +  6  else  Xz-.\n\..z 

Under  the  typing  assumptions  c:bool,  a:int,  and  6:int,  this  expression  may  be 
assigned  the  type  int  int.  A  typical  closure  conversion  algorithm  yields  the 
following  translation: 

if  c  then  (A[e:(int  x  int),a::int].a;  +  tti  e  +  7r2  e,  (a,  6)) 
else  (Ae:(),2::int.z,  0) 

But  this  term  is  not  well-typed  in  a  conventional  typed  A-calculus  since  the 
closure  in  the  then  clause  has  type  (([(int  x  int),  int]  int)  x  (int  x  int)) 
whereas  the  closure  in  the  else  clause  has  type  (([(),  int]  int)  x  ()).  The 
issue  is  that,  at  the  source  level,  int  —>  int  hides  the  type  of  the  environment, 
but  at  the  target  level,  the  type  of  the  environment  is  exposed  in  the  type  of 
the  closure. 

This  problem  of  representation  exposure  may  be  avoided  by  using  an  ex¬ 
istential  type  [7]  to  hide  the  type  of  the  environment.  This  ensures  that  all 
closures  arising  from  a  given  source  language  type  have  the  same  type  after 
closure  conversion.  Specifically,  source  functions  of  type  ri  T2  are  translated 
to  target  closures  with  type  Bo;. (([a,  ri]  T2)  x  a).  This  translation  is  closely 
related  to  Pierce  and  Turner’s  type  system  for  objects  [8]  —  a  function  is  in¬ 
terpreted  as  an  object  with  one  method  (the  code)  and  one  instance  variable 
(the  environment)  using  their  existential  type  discipline  for  simple  objects. 

The  present  work  is  concerned  with  the  extension  of  our  previous  work  to 
account  for  recursively-defined  functions.  This  generalization  introduces  two 
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significant  complications.  First,  several  different  approaches  are  available,  and 
none  dominates  the  others  in  all  respects.  We  consider  here  three  translations: 
one  based  on  recursive  code,  one  based  on  a  self-referential  data  structure, 
and  one  based  on  recursive  types.  Second,  the  correctness  proofs  given  by 
Minamide,  Morrisett,  and  Harper  based  on  logical  relations  must  be  extended 
to  account  for  recursion.  The  general  idea  in  each  case  is  to  relate  the  finite 
approximinants  of  a  recursive  function  to  a  corresponding  finite  approximant 
of  the  target  code.  In  the  case  of  recursive  code  and  self-referential  data 
structures,  the  finite  approximants  are  the  finite  unrollings  of  the  recursive 
code  or  self-referential  structure.  In  the  case  of  recursive  types  we  make  use 
of  the  syntactic  minimal  invariant  associated  with  a  recursive  type  [9,5,4]  to 
define  the  finite  approximants  of  a  value. 

In  the  rest  of  this  abstract,  we  sketch  the  original  simply-typed  closure 
conversion  algorithm  and  the  three  translations  mentioned  above  for  recursive 
functions. 


2  Simply-Typed  Closure  Conversion 


We  formalize  closure  conversion  for  the  simply-typed  lambda  calculus  by  defin¬ 
ing  the  syntax,  static  semantics,  and  dynamic  semantics  for  a  source  language 
(A^)  and  a  target  language  (A^),  by  giving  a  type  translation  T\  1  from  A^ 
types  to  A^  types,  and  a  term  translation  from  well-formed  A“^  terms  to  A^ 
terms. 

The  syntax  for  A”*^  is: 

(types)  T  ::=  b  I  ri  ^  r2 
(terms)  e  ::=  a:  |  c  |  XxiT.e  j  ei  62 

The  language  is  a  conventional  simply-typed  lambda  calculus  with  a  distin¬ 
guished  base  type  (b)  inhabited  by  a  set  of  constants,  over  which  we  use  c 
to  range.  The  static  and  dynamic  semantics  (not  presented  here)  is  entirely 
standard. 

The  syntax  of  our  target  language  A^  is: 

Types  include  products  (for  building  both  environments  and  closures), 
code  (^)  (for  the  code  of  closures)  and  type  variables  and  existentially  quan¬ 
tified  types  (for  hiding  the  type  of  the  environment  of  a  closure).  Our  target 
language  is  iv-edica-i-e  in  that  type  variables  range  over  quantified  as  well 
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as  unquantified  types. 

(types)  T  "=t\b\Ti=^T2\  (ri,  •  •  •  ,rn)  |  3t.r 
(terms)  e  ::=  x  |  c  |  code  (x:r).e  |  call  61(62)  | 

(61  j  *  *  *  j  671)  I  TTj  6  I 

pack[r',  6]  as  r  I  let  t,x  =  unpack  c'  in  6  | 
let  X  =  e'  in  6 

Products  are  introduced  and  eliminated  in  the  usual  fashion.  Code  types 
are  introduced  by  code  terms  and  eliminated  by  call  terms.  Existentials 
are  introduced  by  pack  terms  and  eliminated  by  unpack  terms.  Terms  also 
include  a  let  construct  which  we  use  to  simplify  the  translation. 

The  static  semantics  of  is  also  standard  except  for  the  code  rule  which  is 
similar  to  the  rule  for  A-expressions,  but  requires  that  the  code  definition  con¬ 
tain  no  free  type  variables  or  value  variables.  In  other  words,  code  definitions 
are  always  closed,  and  can  thus  always  be  defined  at  the  top  level. 

The  closure  conversion  translation  is  specified  by  giving  a  type  translation, 
ni  mapping  source  types  to  target  types,  and  a  term  translate  mapping 
derivable  source  language  typing  judgments  to  target  language  terms.  The 
type  translation  is  defined  as: 

TM  =  b 

Tin  ^  T2I  =  TM)  r[[r2l),  t) 

The  arrow  type  Ti  T2  is  translated  to  an  existentially  quantified  value. 
Conceptually,  the  value  is  a  pair  of  an  abstract  type  (t)  and  a  product  value 
whose  type  depends  upon  t.  In  this  situation,  t  will  abstract  the  type  of 
the  environment  of  the  given  closure,  thereby  avoiding  the  typing  problems 
mentioned  in  the  introduction.  The  first  component  of  the  product  value  is 
code  that  takes  a  value  of  the  abstract  environment  type  and  an  argument  of 
type  Tfri]],  and  yields  a  value  of  type  Tlra]].  The  second  component  of  the 
product  value  is  a  value  of  the  abstract  environment  type. 

The  term  translation  is  given  in  Figure  1.  The  var  and  b-I  cases  are 
straightforward.  For  the  ->-I  case,  we  first  translate  the  body  of  the  A- 
expression,  extending  F  with  {x:ri},  to  yield  e'.  We  then  create  a  closed 
piece  of  code  that  abstracts  the  free  variables  of  e'.  The  code  has  a  parameter 
a^axg  which  is  always  a  pair  consisting  of  the  environment  and  the  argument  to 
the  function.  Upon  invocation,  the  code  extracts  these  parameters  and  binds 
them  to  rcenv  and  x  respectively.  (We  assume  that  Xarg  and  x^nv  are  chosen 
so  as  to  be  distinct  from  all  of  the  variables  in  the  context.)  The  values  for 
the  variables  occurring  in  F'  are  obtained  by  performing  suitable  projections 
on  Xenv  and  by  binding  the  result  to  the  appropriate  variable  via  let.  We 
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(var)  r  l±l  {x:t}  hg  x  :  r  x  (b-I)  F  hj  c  ;  b  c 

r  l±)  {x:t}  \-s  e  :  t'  e' 

r  hj  XxiT.e  :  r  ->  r'  pack[Tr,  (ucode,  t^env)]  as  T|r  ->  r']] 
where  F  =  {rcitri,  •  •  • ,  Xn-Tn) 
tt  =  (T[ri]],---,T[r„l) 

^env  ~  (^1) ' '  ■  5  ^n) 

^code  —  code  (^arg •  (^r j  ^ . 

^6iiv  ^1  ^2irg  m 
l6*b  X  7^*2  ^arg 

l0*t  X\  TTj^  iCgjiy  XQ. 


iG't  Xfi  —  TTyj  37ejiv 


(-+-E) 


T  \-s  e\  :  T2 T e\  F  hj  62  :  T2 
F  K  ei  62  :  r 

let  t,a;  =  ;inpack  in  call  {T^\x){{'K2X,e'^) 


{x  ^  I>-t;(F)) 


Fig.  1.  Closure  Conversion  for  A~*^ 


create  the  environment  by  building  a  tuple  {xi,  •  •  •  ,Xn)  containing  the  values 
of  those  variables  in  F.  The  code  and  the  environment  tuple  are  placed  in 
a  pair,  and  the  data  structure  is  packed  in  order  to  abstract  the  type  of  the 
environment. 

For  the  ^-E  case,  we  translate  the  function  and  argument  to  yield  e{  and 
62  respectively.  We  then  unpack  and  bind  the  abstract  type  to  the  type 
variable  t  and  the  contents  of  the  closure  to  x.  We  then  project  the  code  from 
X  followed  by  the  environment,  and  call  the  code  passing  it  the  environment 
and  argument  62- 


3  Recursive  Closure  Conversion 

In  this  section,  we  show  how  to  extend  the  simply-typed  closure  conversion  to 
deal  with  recursive  functions.  Interestingly,  there  are  many  possible  transla¬ 
tions,  each  with  different  tradeoffs  in  terms  of  efficiency  and/ or  complexity  of 
the  resulting  type  system  and  semantics  for  the  target  language.  A  fascinating 
aspect  is  that  all  of  the  translations  presented  here  have  a  direct  correspon- 
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dence  to  type  encodings  used  for  various  kinds  of  object-oriented  languages 
that  support  a  notion  of  “self” . 

Our  source  language  is  the  same  as  A“^,  but  we  extend  values  with  fix- 
expressions  on  abstractions: 


(terms)  e  ::=  •••  |  fix  x{xi:ri):T2.e 


Here,  both  x  and  Xi  are  bound  within  e.  Though  our  source  language  only 
supports  single  recursion,  it  is  straightforward  but  tedious  to  extend  the  pre¬ 
sentation  in  the  following  sections  to  mutual  recursion. 


3.1  The  Fix-C-de  T-a—ua-i-- 


In  this  section,  we  use  recursive  c-de  definitions  in  the  closure  conversion 
translation.  The  translation  is  entirely  straightforward  in  that  the  type  trans¬ 
lation  is  the  same  as  for  simply-typed  closure  conversion  and  no  recursive 
{i.e.,  cyclic)  data  structures  are  required.  Hence,  the  “fix-code”  translation  is 
suitable  for  use  with  a  reference-counting  garbage  collector.  Furthermore,  the 
fix-code  translation  supports  easy  optimization  of  known  functions  as  with  the 
original  translation.  However,  the  implementation  leads  to  unecessary  dupli¬ 
cation  of  closures.  In  essence,  a  copy  of  the  closure  is  re-created  each  time  the 
function  is  invoked. 

The  only  change  to  the  target  language  is  the  addition  of  a  f  ixcode  con¬ 
struct: 


(terms)  e  ::=  •  •  •  |  f ixcode  x{x:Ti):T2.e 


The  code  may  only  refer  to  its  arguments  or  itself.  The  dynamic  semantics 
“unrolls”  the  code  at  the  point  where  it  is  called,  just  as  fix  is  normally 
unrolled. 

Closure  conversion  from  the  source  to  the  target  is  straightforward.  The 
type  translation  remains  the  same,  as  does  the  translation  of  application  and 
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A.  The  only  addition  is  the  translation  rule  for  fix: 


r  W  {x:t’  — >•  T,  x':t'}  e  :  r  e' 

(fix-1)  - i - ^ ^ - ; - 

r  K  fix  x(a;';r'):r.e  :t 

pack[Tr,  (Vcodej  ^env)]  3-S  "T^T  y  T  ]] 

where  F  =  {xi'.ti,- •  ‘  ,Xn'-Tn} 

Tr  =(nTil,-.-,nr„l) 

^env  “  (^Ij '  '  ‘  >  ^n) 

Ucode  =  fixe  ode  a;c(xarg:(rr,T[r]])). 
io^  ^2Lrg  m 

let  x'  =  1^2  Xaig  in 

let  a;  =  pack[rr,  (xcjXenv)]  as  T^r -y  r'}  in 
let  Xi  =  TTi  OJenv  in 


let  Xji  —  TT^  Xqxiv  ia 


The  environment  consists  of  the  free  variables  of  the  body  of  the  function 
except  for  x  (the  function  itself)  and  x'  (the  argument).  The  closure  for  x 
is  constructed  as  before  by  pairing  the  code  with  the  environment.  However, 
e'  is  obtained  from  e  in  a  context  where  x  must  be  available  as  a  closure  - 
not  just  code,  as  the  closure  could  “escape”  {i.e.,  be  passed  as  an  argument 
to  another  function.)  Hence,  once  we  enter  the  code,  we  have  to  construct  a 
“new”  copy  of  the  closure  for  use  within  the  body  of  the  code.  Therefore,  we 
create  a  new  closure  from  Xc  and  rcenv  and  bind  it  to  x.  Of  course,  if  x  is  only 
called  within  the  body  e,  then  the  reductions  can  eliminate  the  unnecessary 
construction  of  this  value.  But  in  general,  we  have  to  allocate  a  new  closure 
pair  each  time  around  the  loop  which  in  practice  actually  is  quite  costly.  The 
other  translations  attempt  to  address  this  by  constructing  the  closure  exactly 
once. 

Note  that  the  situation  is  even  worse  for  mutually  recursive  functions. 
Suppose  we’ve  defined  /i,  •  •  • ,  /n  via  a  letrec.  In  general,  we  have  to  construct 
each  of  the  closures  for  /i ,  •  •  • ,  /n  out  of  the  code  and  shared  environment  each 
time  one  of  these  functions  is  called. 
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3.2  The  Fix- Pact  T-a—ua-i— 


In  our  second  translation,  the  key  idea  is  that  instead  of  adding  recursive  code 
to  the  target  language,  we  add  a  recursive  pack  construct  that  allows  us  to 
define  a  closure  data  structure  in  terms  of  itself.  The  well-known  trick  is  to 
build  a  circular  data  structure  to  represent  fix  closures  where  the  environment 
for  the  closure  contains  the  closure  itself.  In  a  sense,  the  previous  translation 
is  building  this  circular  data  structure  lazily  each  time  the  closure  is  invoked. 
Our  goal  with  this  translation  is  to  build  the  circular  data  structure  once, 
avoiding  the  overhead  of  allocating  a  new  copy  each  time  the  code  is  invoked. 

To  accomplish  this,  we  add  to  the  original  target  language  the  following 
term  constructs: 


(terms)  e  ::=  •  •  •  |  fixpack  x.[t',v]  as  r 

The  new  construct  allows  one  to  define  a  recursive  package  of  existential  type. 
Like  a  recursive  function,  the  variable  x  is  bound  within  the  body  v  of  the 
term. 

With  the  new  target  language  construct,  we  define  the  recursive  closure 
conversion  translation  as  follows:  The  type  translation  is  the  same  as  for  the 
first  two  translations.  The  term  translation  is  also  the  same  for  application 
and  A,  but  the  translation  for  fix  is: 


(flx-2) 


r  W  {x:t  — )■  r',  x':t}  hj  e  :  r'  e' 
r  hg  fix  x(x':T):T'.e  :t  t' 
fixpack  3:.[Tenv>  ('^^codej '^env)]  ^  T  J 

where  F  =  {yi'.Ti,  •  •  • ,  y„:r„} 

renv  =  {TIt  -)•  t'I  ,  Tin} ,  •  •  • ,  Tin} ) 

Veny  =  {x,yi,  •  '  '  ,yn) 

Vcode  =  code  (oJarg  :  (Te„v,  T|[r]]))  :  TIP}. 

lef  Xqhx  ”  ^arg 

let  x'  =  7r2  STarg  iu 
let  X  =  TTi  Xenv  in 
let  yi  =  ^2  Xeny  in 


let  yji  —  T^n+i  ^env  in 
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3.3  The  Fix-Ty-e  -a—ua-i— 

The  previous  translations  used  an  environment-passing  strategy  where  the 
code  of  a  closure  is  passed  the  environment  as  an  extra  argument.  In  this 
translation,  instead  of  passing  the  environment,  we  pass  the  closure  itself  as 
an  extra  argument  to  the  code  of  the  closure.  Right  away,  it’s  obvious  that 
the  closure  must  contain  a  recursive  type  because  the  code  is  contained  in  the 
closure,  but  the  code  takes  the  closure  as  an  argument.  Hence,  a  possible  type 
translation  is  given  by: 


rm  =  b 

7”|[ti  — >  T2J  =  3ienv/^^cl-((^cl)  7”|[ti]|)  7”[[t2]  ,  tenv) 

Given  this,  the  previous  translations  for  application  are  correct,  modulo  the 
insertion  of  an  “unroll”  (assuming  we  want  the  isomorphism  between  the  rolled 
and  unrolled  versions  of  a  recursive  type  to  be  made  explicit); 

,  ^  r  hs  ei  :  r2  -)■  r  e'l  F  62  :  r2  62 

- rh.e,e.:r^ - 

let  t,  a;  =  unpack  e'l  in  call  (tti  (unroll(a;)))(a;,  62) 

The  term  translation  for  fix  becomes: 

r  l±l  {x:ti  — >•  T2,  x':ri}  hg  e  :  r2  e' 


(fix-3) 


r  hg  fix  x{x':Ti):T2.e  ;  ri  ->  T2 
pack[Tr,  roll(('ycode?  ^env)’^ci)]  3.S  y  72]] 

where  F  =  {x\:ti,  •  •  • , 

rr  =(r|Ti],.--,rM) 

Tci  =  Attci.((4i,TIri|)  T|r2|,Tr) 

^env  ”  (^1)  '  "  ‘ 

Wcode  =  code  Xc{Xc\-.Tt\,X:T\TiY)  :  TIt2\. 


let  a:  =  pack[Tr,Xci]  as  Tlri ->  T2]]  in 
let  a;env  =  7r2  (unroll (a^ci))  in 


let  ari  =  tti  a:env  in 


let  Xji  —  TTyj  a:Qiiy  in 
e' 

This  translation  has  all  of  the  (operational)  advantages  of  the  fixpack  ap¬ 
proach.  In  particular,  the  closure  is  only  created  once  and  not  each  time 
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around  the  loop  as  in  the  fixcode  case. 

There  are  a  couple  of  relatively  minor  reasons  why  this  translation  might 
be  preferred  over  the  fixpack  translation:  In  particular,  since  the  code,  not 
the  caller,  extracts  the  environment  from  the  closure,  a  slight  optimization  is 
possible  when  the  environment  is  empty,  as  the  code  can  avoid  projecting  the 
environment.  In  contrast,  for  all  of  the  other  translations,  the  caller  extracts 
the  environment.  Since  the  caller  cannot  in  general  know  the  type  of  the 
environment  (i.e.,  whether  it  is  unit),  the  caller  cannot  know  whether  the 
environment  is  actually  needed  or  not.  Furthermore,  with  suitable  support 
in  the  target  language,  the  environment  can  be  “flattened”  into  the  closure 
tuple.  That  is,  instead  of  (ucodej  "  j^n)),  we  can  represent  the  closure 
as  (ucodej^^i)  iVn)-,  thereby  avoiding  extra  allocation  and  indirection.  It  is 
worth  remarking  that  this  is  the  closure-passing  style  that  Appel  and  Jim 
proposed  in  an  untyped  setting  [2],  and  was  used  until  recently  in  the  SML/NJ 
compiler  [3]. 

Closure-passing  does  have  its  drawbacks:  it  requires  recursive  types  (not 
just  monotonic  types)  which  seriously  complicates  the  semantics  of  the  target 
language,  and  to  reap  the  allocation  benefits,  requires  some  rather  ad  h-c  data 
structures  {e.g.,  pointers  into  the  middle  of  tuples  [1].) 
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